From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: build with clang-3.4 warnings report
Date: Fri, 4 Apr 2014 16:47:01 -0400 [thread overview]
Message-ID: <20140404204701.GO26358@brightrain.aerifal.cx> (raw)
In-Reply-To: <533F0F1A.6040707@embtoolkit.org>
On Fri, Apr 04, 2014 at 09:59:22PM +0200, Abdoulaye Walsimou Gaye wrote:
> src/aio/aio_readwrite.c:20:16: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
> .__si_fields.__sigchld.si_pid = __pthread_self()->pid,
> ~^~~~~~~~~
> src/aio/aio_readwrite.c:18:20: note: previous initialization is here
> .__si_fields.__rt.si_sigval = sev->sigev_value,
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 1 warning generated.
This looks like an actual bug. If these two members overlap, we can't
store both.
> src/ctype/towctrans.c:239:3: warning: add explicit braces to avoid dangling else [-Wdangling-else]
> else return wc + 0x2d00 - 0x10a0;
> ^
> src/ctype/towctrans.c:242:3: warning: add explicit braces to avoid dangling else [-Wdangling-else]
> else return wc + 0x10a0 - 0x2d00;
> ^
> 2 warnings generated.
Bogus, so this looks like one we should disable from configure.
> In file included from src/errno/strerror.c:7:
> src/errno/__strerror.h:100:1: warning: implicit conversion from 'int' to 'unsigned char' changes value from 1133 to 109 [-Wconstant-conversion]
> 1133,
> ^~~~
> 1 warning generated.
I thought this was fixed (and only on mips). The conversion in the
current source is not implicit but explicit.
> src/internal/shgetc.c:16:15: warning: '&&' within '||' [-Wlogical-op-parentheses]
> if (f->shlim && f->shcnt >= f->shlim || (c=__uflow(f)) < 0) {
> ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~ ~~
> src/internal/shgetc.c:16:15: note: place parentheses around the '&&' expression to silence this warning
> if (f->shlim && f->shcnt >= f->shlim || (c=__uflow(f)) < 0) {
> ^
> ( )
> 1 warning generated.
Bogus.
> In file included from src/ipc/semtimedop.c:2:
> In file included from ./include/sys/sem.h:28:
> ../include/endian.h:32:25: warning: '&' within '|' [-Wbitwise-op-parentheses]
> return __x>>24 | __x>>8&0xff00 | __x<<8&0xff0000 | __x<<24;
> ~ ~~~~~~^~~~~~~
> ../include/endian.h:32:25: note: place parentheses around the '&' expression to silence this warning
> return __x>>24 | __x>>8&0xff00 | __x<<8&0xff0000 | __x<<24;
> ^
> ( )
> ../include/endian.h:32:41: warning: '&' within '|' [-Wbitwise-op-parentheses]
> return __x>>24 | __x>>8&0xff00 | __x<<8&0xff0000 | __x<<24;
> ~ ~~~~~~^~~~~~~~~
> ../include/endian.h:32:41: note: place parentheses around the '&' expression to silence this warning
> return __x>>24 | __x>>8&0xff00 | __x<<8&0xff0000 | __x<<24;
> ^
> ( )
> ../include/endian.h:37:23: warning: operator '<<' has lower precedence than '+'; '+' will be evaluated first [-Wshift-op-parentheses]
> return __bswap32(__x)+0ULL<<32 | __bswap32(__x>>32);
> ~~~~~~~~~~~~~~^~~~~~~
> ../include/endian.h:37:23: note: place parentheses around the '+' expression to silence this warning
> return __bswap32(__x)+0ULL<<32 | __bswap32(__x>>32);
> ^
> ( )
> 3 warnings generated.
Another bogus one. Does -Wno-parentheses fail to silence these?
> src/locale/iconv.c:323:7: warning: adding 'unsigned int' to a string does not append to the string [-Wstring-plus-int]
> +c%256}, &(size_t){4},
> ^~~~~~
> src/locale/iconv.c:323:7: note: use array indexing to silence this warning
> +c%256}, &(size_t){4},
> ^
Another bogus one.
> src/math/fma.c:334:15: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas]
> #pragma STDC FENV_ACCESS ON
> ^
> 1 warning generated.
We have -Wno-unknown-pragmas... so why is this appearing?
> src/regex/regcomp.c:2659:24: warning: equality comparison with extraneous parentheses [-Wparentheses-equality]
> if (((lit)->code_min == -4))
> ~~~~~~~~~~~~~~~~^~~~~
> src/regex/regcomp.c:2659:24: note: remove extraneous parentheses around the comparison to silence this warning
> if (((lit)->code_min == -4))
> ~ ^ ~
> src/regex/regcomp.c:2659:24: note: use '=' to turn this equality comparison into an assignment
> if (((lit)->code_min == -4))
> ^~
> =
> 1 warning generated.
Another one, but these parens could be removed. I think they're a
leftover from removing other conditions in the same if statement.
> src/time/localtime_r.c:9:9: warning: comparison of constant -67908586910515200 with expression of type 'const time_t' (aka 'const long') is always false [-Wtautological-constant-out-of-range-compare]
> if (*t < (-1-0x7fffffff) * 31622400LL || *t > 0x7fffffff * 31622400LL) {
> ~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> src/time/localtime_r.c:9:46: warning: comparison of constant 67908586878892800 with expression of type 'const time_t' (aka 'const long') is always false [-Wtautological-constant-out-of-range-compare]
> if (*t < (-1-0x7fffffff) * 31622400LL || *t > 0x7fffffff * 31622400LL) {
> ~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~
> 2 warnings generated.
More bogus. It's not tautological; it's arch-specific whether it can
be true or not.
The second half of the email was all duplicates from the shared
library build.
Rich
next prev parent reply other threads:[~2014-04-04 20:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-04 19:59 Abdoulaye Walsimou Gaye
2014-04-04 20:47 ` Rich Felker [this message]
2014-04-05 1:06 ` Abdoulaye Walsimou Gaye
2014-04-05 1:54 ` Rich Felker
2014-04-05 9:04 ` Jens Gustedt
2014-04-05 9:31 ` Szabolcs Nagy
2014-04-05 13:07 ` Rich Felker
2014-04-05 14:37 ` Jens Gustedt
2014-04-05 16:35 ` Rich Felker
2014-04-05 22:08 ` Jens Gustedt
2014-04-06 1:57 ` Rich Felker
2014-04-06 16:37 ` Jens Gustedt
2014-04-06 16:49 ` Rich Felker
2014-04-07 11:17 ` Oliver Schneider
2014-04-07 17:23 ` Rich Felker
2014-04-07 19:40 ` Abdoulaye Walsimou Gaye
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140404204701.GO26358@brightrain.aerifal.cx \
--to=dalias@aerifal.cx \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).