On Thu, 19 Jul 2018, Justin Hibbits wrote:

Log:
 Revert r336509.  Fails buildworld.

 I had naively assumed that building kernel would be sufficient to test that
 the header is sane.  However, it turns out this now needs -fms-extensions to
 build.  Rather than sprinkling -fms-extensions all over the place, revert
 for now, and revisit with a better fix.

-ms-extensions is bogus.  Try using the correct C nonstandard (-std=gnu99,
not -std=c99).  Unnamed struct/unions are an old gcc extension.  They are
also given by -std-gnu89 and might have been in gcc-1 before ms.
-fms-extensions gives small further extensions for unnamed struct unions,
and other ms extensions which are not wanted.

Since buildworld already uses the correct C nonstandard, the location of
the problem is unclear.  It is the kernel that uses -std=c99.  This asks
for C99 compiler, but clang -std=c99 is very far from being a C99 compiler.
One of its bugs is that it gives -ms-extensions by default.  This bug is
missing in gcc.  This is worked around by adding -fms-extensions for gcc
in kern.pre.mk and kmod.mk.

gcc -std=c99 is also very far from being a C99 compiler.  Very little of
the kernel is written in strict C99, and not all parts are careful to use
__extension__ and other things with underscores when they use extensions.
It takes -pedantic as well as -std to get closer to being a C compiler.

Userland is loser to being written in strict C, but it knows that it isn't
and has used -std=gnu99 instead of -std=c99 to get hnu extensions
automatically in all or almost all versions that use -std at all.  This
is of course only for the FreeBSD source tree part of userland --
bsd.sys.mk file adds this -std for FreeBSD builds.

Overriding the broken -std setting is also broken in the kernel.  The
setting is supposed to be controlled by the user-settable variable
CSTD.  bsd.sys.mk implements this using CSTD?=gnu99, but kern.mk forces
CSTD=c99.  The -ms-extensions wart on this is also forced for gcc.

Anyway, user headers shouldn't depend on nonstandard extensions even when
the system compiler and mk files support the extensions.  So backing this
out might be the correct fix.

Bruce
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to