Message ID | Yn6H+ie6JwP3t05E@redhat.com |
---|---|
State | New |
Headers | show |
Series | Check for ISO C compilers should also allow C++ | expand |
* Jonathan Wakely: > The check for an ISO C compiler assumes that anything GCC-like will > define __STDC__, even if it's actually a C++ compiler. That's currently > true for G++ and compilers like clang++ that also define __GNUC__, but > it might not always be true. > > The C++ standard leaves it implementation-defined whether or not > __STDC__ is defined by C++ compilers. And really the check should be > "ISO C or ISO C++ conforming compiler" anyway. > --- > misc/sys/cdefs.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/misc/sys/cdefs.h b/misc/sys/cdefs.h > index f1faf8292c..aab0e7f6a9 100644 > --- a/misc/sys/cdefs.h > +++ b/misc/sys/cdefs.h > @@ -27,8 +27,8 @@ > /* The GNU libc does not support any K&R compilers or the traditional mode > of ISO C compilers anymore. Check for some of the combinations not > supported anymore. */ > -#if defined __GNUC__ && !defined __STDC__ > -# error "You need a ISO C conforming compiler to use the glibc headers" > +#if defined __GNUC__ && !defined __STDC__ && !defined __cplusplus > +# error "You need a ISO C or C++ conforming compiler to use the glibc headers" > #endif > > /* Some user header file might have defined this before. */ The change and commit message make sense to me. We can backport this, too. Thanks, Florian
On Fri, 13 May 2022, Jonathan Wakely via Libc-alpha wrote: > Tested x86_64-linux. > > There is a suggestion[1] to make clang++ stop defining __STDC__ but it's > blocked by this. The clang++ change will still be blocked while old > Glibc versions are still in use, but we can start the clock ticking by > fixing Glibc now. > > [1] https://discourse.llvm.org/t/rfc-stop-defining-the-stdc-and-related-macros-in-c-mode/62468/1 > > >From a quick grep, I don't think any other places in Glibc need a > similar change. Florian pointed out that gnulib overrides > <sys/cdefs.h> and so should make the same change in its version. The change seems sane. While we don't document what extensions (beyond C90 / C++98) are needed to use glibc's headers (e.g. long long, flexible array members, anonymous structs / unions; in at least some cases, alignment attributes and asm redirection of functions), I see no reason defining __STDC__ in C++ should be such a required extension.
On Fri, 13 May 2022 at 18:28, Joseph Myers wrote: > > On Fri, 13 May 2022, Jonathan Wakely via Libc-alpha wrote: > > > Tested x86_64-linux. > > > > There is a suggestion[1] to make clang++ stop defining __STDC__ but it's > > blocked by this. The clang++ change will still be blocked while old > > Glibc versions are still in use, but we can start the clock ticking by > > fixing Glibc now. > > > > [1] https://discourse.llvm.org/t/rfc-stop-defining-the-stdc-and-related-macros-in-c-mode/62468/1 > > > > >From a quick grep, I don't think any other places in Glibc need a > > similar change. Florian pointed out that gnulib overrides > > <sys/cdefs.h> and so should make the same change in its version. > > The change seems sane. While we don't document what extensions (beyond > C90 / C++98) are needed to use glibc's headers (e.g. long long, flexible > array members, anonymous structs / unions; in at least some cases, > alignment attributes and asm redirection of functions), I see no reason > defining __STDC__ in C++ should be such a required extension. Right. Its meaning in ISO C++ is entirely implementation-defined, and G++ doesn't document any particular meaning for it, and clang++ doesn't either AFAIK, and follows a slightly different set of rules for when it's defined (see the link above). So in C++ the only thing that __STDC__ being defined tells you is that __STDC__ is defined :-) That's not a very useful thing to test for in isolation.
On 2022-05-13, Jonathan Wakely via Libc-alpha wrote: >On Fri, 13 May 2022 at 18:28, Joseph Myers wrote: >> >> On Fri, 13 May 2022, Jonathan Wakely via Libc-alpha wrote: >> >> > Tested x86_64-linux. >> > >> > There is a suggestion[1] to make clang++ stop defining __STDC__ but it's >> > blocked by this. The clang++ change will still be blocked while old >> > Glibc versions are still in use, but we can start the clock ticking by >> > fixing Glibc now. >> > >> > [1] https://discourse.llvm.org/t/rfc-stop-defining-the-stdc-and-related-macros-in-c-mode/62468/1 >> > >> > >From a quick grep, I don't think any other places in Glibc need a >> > similar change. Florian pointed out that gnulib overrides >> > <sys/cdefs.h> and so should make the same change in its version. >> >> The change seems sane. While we don't document what extensions (beyond >> C90 / C++98) are needed to use glibc's headers (e.g. long long, flexible >> array members, anonymous structs / unions; in at least some cases, >> alignment attributes and asm redirection of functions), I see no reason >> defining __STDC__ in C++ should be such a required extension. > >Right. Its meaning in ISO C++ is entirely implementation-defined, and >G++ doesn't document any particular meaning for it, and clang++ >doesn't either AFAIK, and follows a slightly different set of rules >for when it's defined (see the link above). So in C++ the only thing >that __STDC__ being defined tells you is that __STDC__ is defined :-) >That's not a very useful thing to test for in isolation. > I agree with the spirit of the clang RFC but I am sad to know that glibc sys/cdefs.h blocks it. Thanks for sending the patch! It seems that the subject may be clearer if starting with "<sys/cdefs.h>: ..." In addition, It will be clearer if the token `__STDC__` is mentioned on the subject line. Reviewed-by: Fangrui Song <maskray@google.com>
On Sat, 14 May 2022 at 07:46, Fangrui Song <maskray@google.com> wrote: > > On 2022-05-13, Jonathan Wakely via Libc-alpha wrote: > >On Fri, 13 May 2022 at 18:28, Joseph Myers wrote: > >> > >> On Fri, 13 May 2022, Jonathan Wakely via Libc-alpha wrote: > >> > >> > Tested x86_64-linux. > >> > > >> > There is a suggestion[1] to make clang++ stop defining __STDC__ but it's > >> > blocked by this. The clang++ change will still be blocked while old > >> > Glibc versions are still in use, but we can start the clock ticking by > >> > fixing Glibc now. > >> > > >> > [1] https://discourse.llvm.org/t/rfc-stop-defining-the-stdc-and-related-macros-in-c-mode/62468/1 > >> > > >> > >From a quick grep, I don't think any other places in Glibc need a > >> > similar change. Florian pointed out that gnulib overrides > >> > <sys/cdefs.h> and so should make the same change in its version. > >> > >> The change seems sane. While we don't document what extensions (beyond > >> C90 / C++98) are needed to use glibc's headers (e.g. long long, flexible > >> array members, anonymous structs / unions; in at least some cases, > >> alignment attributes and asm redirection of functions), I see no reason > >> defining __STDC__ in C++ should be such a required extension. > > > >Right. Its meaning in ISO C++ is entirely implementation-defined, and > >G++ doesn't document any particular meaning for it, and clang++ > >doesn't either AFAIK, and follows a slightly different set of rules > >for when it's defined (see the link above). So in C++ the only thing > >that __STDC__ being defined tells you is that __STDC__ is defined :-) > >That's not a very useful thing to test for in isolation. > > > > I agree with the spirit of the clang RFC but I am sad to know that glibc sys/cdefs.h blocks it. > Thanks for sending the patch! > > It seems that the subject may be clearer if starting with "<sys/cdefs.h>: ..." > > In addition, It will be clearer if the token `__STDC__` is mentioned on the subject line. > > Reviewed-by: Fangrui Song <maskray@google.com> I made the suggested changes to the commit message and pushed the patch, thanks for the reviews.
diff --git a/misc/sys/cdefs.h b/misc/sys/cdefs.h index f1faf8292c..aab0e7f6a9 100644 --- a/misc/sys/cdefs.h +++ b/misc/sys/cdefs.h @@ -27,8 +27,8 @@ /* The GNU libc does not support any K&R compilers or the traditional mode of ISO C compilers anymore. Check for some of the combinations not supported anymore. */ -#if defined __GNUC__ && !defined __STDC__ -# error "You need a ISO C conforming compiler to use the glibc headers" +#if defined __GNUC__ && !defined __STDC__ && !defined __cplusplus +# error "You need a ISO C or C++ conforming compiler to use the glibc headers" #endif /* Some user header file might have defined this before. */