Apologies if this was discussed before, but it is hard to search for terms such as -std=c11.
There is a tendency in many projects to force -std=c* or -std=c++* to ensure a certain level of language compatibility. Unfortunately, many of these projects then expect to find POSIX or other extensions. QNX (at least) interprets -std=c* as strict ISO C without extensions, and I believe this interpretation is correct - you do not want to contaminate the user name space unless an extension was requested. (Of course, I may be wrong and would be glad to be corrected.)
Now, it is possible to override these with extra compiler flags, until you encounter a composite project that aggregates different subprojects with different build systems. Then things become really complicated (most recent example are graphene and libsoup being built as part of gstreamer).
Any thoughts on switching to something like -std=gnu* as the standard, or adding something like -D_POSIX_C_SOURCE=xxx by default?
When a base standard is specified, the compiler accepts all programs following that standard plus those using GNU extensions that do not contradict it. For example, -std=c90 turns off certain features of GCC that are incompatible with ISO C90, such as the “asm” and “typeof” keywords, but not other GNU extensions that do not have a meaning in ISO C90, such as omitting the middle term of a “?:” expression.
There is no way to get the behavior you want, but the closest thing would be -Werror=pedantic -pedantic-errors. These flags are not commonly used in GNOME.
Honestly I think it’s up to project maintainers. Personally, I prefer to use -std=c* and avoid GNU-specific language extensions. They are just not very useful. But I understand some maintainers prefer otherwise. -std=gnu* is the default, so that’s what most projects use.
Regardless, if you submit a merge request to fix things for QNX, I hope it would generally be accepted. Hopefully.
This one is already defined by default by glibc, unless you are defining other feature test macros. Check the example program at the bottom of feature_test_macros(7).
Thanks for the comments.
That glibc defines _POSIX_C_SOURCE automatically is the crux of the matter - this is not the case with the QNX C library, because of the name space pollution concern. In theory, you should be able to write your own open, read, pthread_* etc. and if you compile with -std=c* you should not have to worry about headers conflicting with your code.
Does it matter? I’m not sure. I’ve been arguing the opposite with our tools maintainers, but mainly out of “but everybody else does it this way” stand. It often feels like Netscape people claiming IE6 is not standards compliant in the mid 2000s - may be true, but irrelevant
Oh wow, that’s pretty unusual. So by default you have standard C but not any standard POSIX? I suspect you’ll have trouble compiling almost every open source project!
Here is my suggestion: if you can’t convince the C library to be more pragmatic, then I would define _POSIX_C_SOURCE to some reasonable default value in your packaging.
This is not a big deal with most projects though. Even those that define -std=c* would typically allow something like CFLAGS=-std=gnu11 to override it, or CFLAGS=-D_POSIX_C_SOURCE=200809 to be added (substitute for cmake/meson/Scons method). But yes, it’s a pain.
With older versions of Meson, projects can only select one C/C++ standard, so the general recommendation is to always use c_std=gnuXX instead of c_std=cXX; Meson will fall back to the most compatible version of the standard on other compilers, like MSVC, where “GNU compiler extensions” do not apply.
Starting from Meson 1.3, the c_std and cpp_std options accept a list of values; thus the recommendation for GNOME projects that can depend on Meson ≥ 1.3 should be to use c_std=gnuXX,cXX.
In general, though, GNOME projects that do not care about portability on the MSVC toolchain should always select gnuXX.
Never, ever use -pedantic, -pedantic-errors, or -Werror=pedantic with code that depends on GLib. GLib’s toolchain requirements prevent the use of “pedantic”/strict ISO C compliance. If you decide to enable pedantic errors you are completely on your own, and no fix will be ever be upstreamable.
