On Mon, Oct 26, 2015 at 12:32:01PM +0000, Szabolcs Nagy wrote: > On 23/10/15 21:20, Joseph Myers wrote: > >On Fri, 23 Oct 2015, Szabolcs Nagy wrote: > > > >>i think bsd libcs do the same, compiler headers interfering > >>with libc headers is problematic (e.g. FLT_ROUNDS is wrong > >>in gcc float.h, applications shouldn't see that), i'm not sure > > > >FLT_ROUNDS is an ordinary compiler bug (bug 30569), should be fixable > >reasonably straightforwardly as outlined at > ><https://gcc.gnu.org/ml/gcc/2013-11/msg00317.html>, probably within say a > >week's work if most architecture-specific changes are left to architecture > >maintainers. > > musl tries to support old compilers in general (it can be built > with gcc 3.x, and it should be possible to use with a wider range > of compilers with reasonably consistent semantics, so fixing that > bug in gcc does not help much.) > > a better example would be stddef.h (it has incompatible definition > of NULL, max_align_t etc, the ifdefs in gcc are fragile and none > of the __need_FOO patterns match the ones musl use). > > i think in general the higher level layer should come first > (c++ first, then libc, then compiler include paths), so the one > closer to the user gets a chance to override the ones after it, > stdc-predef.h was a good step toward that.
musl explicitly does not support using a mix of libc headers and compiler-provided freestanding headers. While there may be circumstances under which no effective breakage occurs, this is merely by chance and is not a supported usage. No effort is made by musl to interact with the gcc headers (e.g. defining the macros they use to prevent multiple definitions or control multiple inclusion, or testing for whether they have already been included are made). It is necessary to use the BSD-style header order, so that the libc headers get used instead of the compiler-provided ones, to have a reliable musl target. Rich
