Hi Collin, Thanks for working on this. > With GCC 15 and C++26 the result is (*): > > $ ./configure CFLAGS='-std=gnu99' CXXFLAGS='-std=gnu++26' | grep stdckdint > checking for stdckdint.h... yes > checking whether stdckdint.h can be included in C... yes > checking whether stdckdint.h defines ckd_add, ckd_sub, ckd_mul in C... yes > checking whether stdckdint.h can be included in C++... yes > checking whether stdckdint.h defines ckd_add, ckd_sub, ckd_mul in C++... > yes > $ make > $ ls gllib/stdckdint.h > ls: cannot access 'gllib/stdckdint.h': No such file or directory > > And with GCC 15 and C++14: > > $ ./configure CFLAGS='-std=gnu99' CXXFLAGS='-std=gnu++14' | grep stdckdint > checking for stdckdint.h... yes > checking whether stdckdint.h can be included in C... yes > checking whether stdckdint.h defines ckd_add, ckd_sub, ckd_mul in C... yes > checking whether stdckdint.h can be included in C++... yes > checking whether stdckdint.h defines ckd_add, ckd_sub, ckd_mul in C++... > no > $ make > $ ls gllib/stdckdint.h > gllib/stdckdint.h > > In the second case, when compiling a C program <stdckdint.h> simply does > an #include_next.
Yes, that's the expected behaviour. Reviewing the patch: It's nearly right, except: 1) In m4/stdckdint.m4: + if test $HAVE_STDCKDINT_H == 1; then '==' is an invalid operator for 'test'. See https://pubs.opengroup.org/onlinepubs/9799919799/utilities/test.html or https://www.man7.org/linux/man-pages/man1/test.1.html . (It may be a bash extension.) 2) In lib/stdckdint.in.h: Due to the #include_next, you need the /* The include_next requires a split double-inclusion guard. */ idiom, found e.g. in mntent.in.h. 3) "checking whether stdckdint.h defines ckd_add, ckd_sub, ckd_mul in C..." This message is a bit long and technical. Can you try to shorten it? Such as "checking for an ISO C23 compliant stdckdint.h in C..." ? > (*) I find it strange that the C++ declarations are hidden depending on > the C++ standard, but the C ones are not. I would expect -std=(gnu|c)99 > to disable them like the C++ version. It seems that the GCC developers, for the C language, like to make stuff from newer standards available with older -std options. Whereas the libstdc++ and glibc developers prefer to follow the standard specified through -std to the letter. Each of the approaches has its upsides and downsides. I don't think it's worth reporting one or the other as a "bug". Bruno
