_ISOCxx_SOURCE
Alejandro Colomar
maintainerHi!
I was reviewing the feature_test_macros(7) page, and found the documentation of the _ISOC{99,11,23,...}_SOURCE macros to be incorrect. And thinking about fixing that led me to think that the design of those macros is less than ideal.
Here's for example some of the problematic text:
Defining _ISOC23_SOURCE also enables C11, C99, and C95 features.
The above is not true. See for example some contradicting (and also incorrect/incomplete) text in the HISTORY section of gets(3):
glibc header files don’t expose the function declaration if the _ISOC11_SOURCE feature test macro is defined.
gets(3) is a C89 and C99 feature, which is disabled with C11 and later standard versions. The text saying that _ISOC23_SOURCE enables older features is only true as much as those features remain in the C23 standard. And in gets(3), we should say that the function is not exposed on C11 or later (not just C11).
A better design of this macro would be to have a single identifier, and use a value to specify the version. This is how POSIX does it. We could call it _ISO_C_SOURCE, and have a value such as 202311L for requesting C23. That would make it easier to describe: features are available within a range of versions; often a half-bounded interval, starting at a version, and not ending; but other times a bounded interval, starting at a version, and ending at another version.
What do you think?
Have a lovely day!
Alex
Signature · 1 line
<https://www.alejandro-colomar.es>
Quoted 4 lines · Alejandro Colomar via Gcc
I was reviewing the
feature_test_macros(7)page, and found the documentation of the _ISOC{99,11,23,...}_SOURCE macros to be incorrect. And thinking about fixing that led me to think that the design of those macros is less than ideal.
Users should normally use -std= options with the compiler to get matching language and library features. These feature test macros are mainly for niche cases with old compilers. So I don't think any new user-facing design for them should be added (the C23 and later ones already use the newer __GLIBC_USE style of conditionals in the header implementation).
Signature · 2 lines
Joseph S. Myers [email protected]
Alejandro Colomar
maintainerHi Joseph,
Quoted 7 lines · Joseph Myers
Quoted 4 lines · Alejandro Colomar via Gcc
I was reviewing the
feature_test_macros(7)page, and found the documentation of the _ISOC{99,11,23,...}_SOURCE macros to be incorrect. And thinking about fixing that led me to think that the design of those macros is less than ideal.
Quoted 5 lines
Users should normally use -std= options with the compiler to get matching language and library features. These feature test macros are mainly for niche cases with old compilers. So I don't think any new user-facing design for them should be added (the C23 and later ones already use the newer
__GLIBC_USEstyle of conditionals in the header implementation).
Makes sense. Should I document that users should avoid setting them directly (and that they should use the corresponding compiler flag)?
Have a lovely night!
Alex
Signature · 1 line
<https://www.alejandro-colomar.es>
Quoted 10 lines · Alejandro Colomar
Hi Joseph,
Quoted 7 lines · Joseph Myers
Quoted 4 lines · Alejandro Colomar via Gcc
I was reviewing the
feature_test_macros(7)page, and found the documentation of the _ISOC{99,11,23,...}_SOURCE macros to be incorrect. And thinking about fixing that led me to think that the design of those macros is less than ideal.
Quoted 8 lines
Quoted 5 lines
Users should normally use -std= options with the compiler to get matching language and library features. These feature test macros are mainly for niche cases with old compilers. So I don't think any new user-facing design for them should be added (the C23 and later ones already use the newer
__GLIBC_USEstyle of conditionals in the header implementation).Makes sense. Should I document that users should avoid setting them directly (and that they should use the corresponding compiler flag)?
Indeed. Also, users are probably using a compiler defaulting to -std=gnu23 or -std=gnu11 so the older _ISOC99_SOURCE and _ISOC11_SOURCE are doubly irrelevant for that reason.
Signature · 2 lines
Joseph S. Myers [email protected]
Alejandro Colomar
maintainerHi Joseph,
Quoted 18 lines · Joseph Myers
Quoted 16 lines · Alejandro Colomar
Hi Joseph,
Quoted 12 lines · Joseph Myers
Quoted 4 lines · Alejandro Colomar via Gcc
I was reviewing the
feature_test_macros(7)page, and found the documentation of the _ISOC{99,11,23,...}_SOURCE macros to be incorrect. And thinking about fixing that led me to think that the design of those macros is less than ideal.Users should normally use -std= options with the compiler to get matching language and library features. These feature test macros are mainly for niche cases with old compilers. So I don't think any new user-facing design for them should be added (the C23 and later ones already use the newer
__GLIBC_USEstyle of conditionals in the header implementation).
Quoted 4 lines
Quoted 2 lines
Makes sense. Should I document that users should avoid setting them directly (and that they should use the corresponding compiler flag)?
Indeed.
Thanks! Will do.
Quoted 3 lines
Also, users are probably using a compiler defaulting to
-std=gnu23 or -std=gnu11 so the older_ISOC99_SOURCEand_ISOC11_SOURCEare doubly irrelevant for that reason.
I was also wondering...
If one uses a modern GCC with an old glibc (which doesn't know C23), then, using -std=c23 will be problematic: the compiler will enable C23 language mode, but the library will entirely and silently ignore _ISOC23_SOURCE, because it doesn't know about it, thus falling back to C89 mode (I guess), and thus will for example enable things like gets(3).
If the way to pass the language version from the compiler to the libc were through a single macro, then the library would be able to at least diagnose, and/or turn on the latest dialect it knows about.
Is there any limitation of which libc versions are supported by modern GCC? Is this a bug?
Have a lovely night!
Alex
Quoted 5 lines
Signature · 3 lines
-- Joseph S. Myers [email protected]
Signature · 1 line
<https://www.alejandro-colomar.es>
Quoted 6 lines · Alejandro Colomar via Gcc
If one uses a modern GCC with an old glibc (which doesn't know C23), then, using -std=c23 will be problematic: the compiler will enable C23 language mode, but the library will entirely and silently ignore
_ISOC23_SOURCE, because it doesn't know about it, thus falling back to C89 mode (I guess), and thus will for example enable things like gets(3).
Since the relevant checks in features.h are based on __STDC_VERSION__ > something or __STDC_VERSION__ >= something, it will fall back to the most recent C standard version known by that glibc version, which is probably what you want.
Signature · 2 lines
Joseph S. Myers [email protected]
Alejandro Colomar
maintainerHi Joseph,
Quoted 11 lines · Joseph Myers
Quoted 6 lines · Alejandro Colomar via Gcc
If one uses a modern GCC with an old glibc (which doesn't know C23), then, using -std=c23 will be problematic: the compiler will enable C23 language mode, but the library will entirely and silently ignore
_ISOC23_SOURCE, because it doesn't know about it, thus falling back to C89 mode (I guess), and thus will for example enable things like gets(3).Since the relevant checks in
features.hare based on__STDC_VERSION__> something or__STDC_VERSION__>= something,
Ahh, yup, it has || for either _ISOCxx_SOURCE or __STDC_VERSION__. That makes sense.
Quoted 3 lines
it will fall back to the most
recent C standard version known by that glibc version, which is probably what you want.
Hmmm, it is. Then it's all fine. Thanks!
Cheers,
Alex
Signature · 1 line
<https://www.alejandro-colomar.es>