Why can't gcc find the random() interface when -std=c99 is set?

前端 未结 4 1822
借酒劲吻你
借酒劲吻你 2020-12-15 06:26

I do \"#include \" at the top of the source.

Example compilation:

/usr/bin/colorgcc -std=c99 -fgnu89-inline  -g -Wall -I         


        
4条回答
  •  渐次进展
    2020-12-15 06:54

    Yes, there is a trick you are missing: you can use -std=gnu99 instead of -std=c99.

    -std=c99 #defines __STRICT_ANSI__, which /usr/include/features.h interprets as "do not enable anything outside the C standard by default" (without it, you get at least both _SVID_SOURCE and _BSD_SOURCE). -std=gnu99, on the other hand, means "C99 plus GNU extensions" (the gcc default is currently -std=gnu89, its C89 equivalent, which is why you needed to specify something to get the new C99 features).

    As an alternative, you can enable the feature test macros (as mentioned in @litb's answer). Looking at /usr/include/stdlib.h in my system, it expects one of __USE_SVID, __USE_XOPEN_EXTENDED, or __USE_BSD. /usr/include/features.h tells me that the feature test macros which would enable these are:

    • _SVID_SOURCE (enables __USE_SVID)
    • _BSD_SOURCE (enables __USE_BSD)
    • _XOPEN_SOURCE with a value of at least 500 (enables __USE_XOPEN_EXTENDED)
    • _XOPEN_SOURCE_EXTENDED (also enables __USE_XOPEN_EXTENDED)
    • _GNU_SOURCE (enables everything, including the four feature test macros above)

    For new programs where you are not too concerned about potential name collisions with new functions from future standards, using both -std=gnu99 and -D_GNU_SOURCE is a good idea. It allows you to use all the new standard features and GNU extensions, which combined with some sort of fallback (for instance, autoconf-style feature tests) gives the most flexibility.

    References:

    • Options Controlling C Dialect
    • Feature Test Macros

提交回复
热议问题