Re: Fix warnings when build with clang

[Rich Felker <dalias@libc.org>]

On Mon, Jun 27, 2016 at 07:41:49PM +0200, Luca Barbato wrote:
> On 27/06/16 19:21, Rich Felker wrote:
> > On Mon, Jun 27, 2016 at 10:01:52AM -0700, weimingz@codeaurora.org wrote:
> >> On 2016-06-25 02:37, Szabolcs Nagy wrote:
> >>> * Zhao, Weiming <weimingz@codeaurora.org> [2016-06-24 17:18:23 -0700]:
> >>>> Clang gives warnings about the missing parentheses for bitwise ops.
> >>>>
> >>>> It's not functional but just code readability.
> >>>>
> >>>> musl-m3/include/endian.h:32:25: warning: '&' within '|'
> >>>> [-Wbitwise-op-parentheses]
> >>>>        return __x>>24 | __x>>8&0xff00 | __x<<8&0xff0000 | __x<<24;
> >>>>                       ~ ~~~~~~^~~~~~~
> >>>
> >>> if clang warns about system headers that's a clang bug.
> >>
> >> The endian.h is a musl file.
> > 
> > Right, which is why it's a system header.
> 
> I'm not sure there is a simple way to know what's a system header and
> what is not, beside keeping a list.

If your compiler is automatically searching the right system header
paths for the target, it's a non-issue. If not (if you have some
hacked-together setup) then you should use -isystem rather than -I for
the system header path.

> And even in that case I'm not so sure the compiler should hide warnings
> (no matter how fringe this actual warning is).

The intent of style warning options (which this one is) is to warn
about issues in the code being compiled, where it does not meet the
policy set for the project being compiled. It's not to warn that libc
does not meet your project's arbitrary style policies. This one
happens to be turned on by -Wall I think, but there are lots of other
style-policy warning options the user could turn on which musl's
headers are cerainly not going to try to comply with, so the proper
solution is for the compiler not to apply the style policy to them.

Rich