cdefs: Assume __GNUC__ defined

[imp]

Summary

Assume that the compiler supports the GNUC class of preprocessor
directives. Clang and gcc do, which are the only really supported
compilers for the tree.

[kib]

The bigger part of !GNUC support is in machine/atomic.h.

In fact having gnuc-isms clearly marked is a useful feature.

[imp]

In D26818#597997, @kib wrote:

The bigger part of !GNUC support is in machine/atomic.h.

One file at a time...

In fact having gnuc-isms clearly marked is a useful feature.

Everything in this file is a gnu ism... no?

[kib]

In D26818#598018, @imp wrote:

In D26818#597997, @kib wrote:

In fact having gnuc-isms clearly marked is a useful feature.

Everything in this file is a gnu ism... no?

No, I do not view it this way. First, there is enough stuff not related to GNU C extensions. Starting from the compat shims for c89 or even K&R (but some stuff like static assert or array sizing in args, is really for c99), POSIX/XSI/BSD visibility macros, ending in thread-local shims etc that do not require gnu-isms.

Then, there is relatively small core stuff that almost consistently marked with GNUC or guarded by global define (e.g. GNUCLIKE_ASM). The rest is built on top of these wrapped gnu-isms.

I was surprised to remind myself that we even care to wrap _compiler_member() with ifdef GNU_C.

May be it would be fine to do the stripping that you propose, but move affected cdefs.h into cdefs-gcc.h and have cdefs.h

#ifdef __GNUC__
#include <sys/cdefs-gcc.h>
#endif

keeping e.g. posix visibility maze of defines in cdefs.h.

[imp]

In D26818#598049, @kib wrote:

In D26818#598018, @imp wrote:

In D26818#597997, @kib wrote:

In fact having gnuc-isms clearly marked is a useful feature.

Everything in this file is a gnu ism... no?

No, I do not view it this way. First, there is enough stuff not related to GNU C extensions. Starting from the compat shims for c89 or even K&R (but some stuff like static assert or array sizing in args, is really for c99), POSIX/XSI/BSD visibility macros, ending in thread-local shims etc that do not require gnu-isms.

Do you have a compiler I can test whatever I come up with then? I don't mean to be difficult, but if there's no way to test it, there's no way to know if the ancient stuff even works.

Then, there is relatively small core stuff that almost consistently marked with GNUC or guarded by global define (e.g. GNUCLIKE_ASM). The rest is built on top of these wrapped gnu-isms.

I was surprised to remind myself that we even care to wrap _compiler_member() with ifdef GNU_C.

May be it would be fine to do the stripping that you propose, but move affected cdefs.h into cdefs-gcc.h and have cdefs.h

#ifdef __GNUC__
#include <sys/cdefs-gcc.h>
#endif

keeping e.g. posix visibility maze of defines in cdefs.h.

I really dislike this idea. GNUC has sadly become standardized in all compilers that want to be taken seriously, so it's lost a lot of its original specialness. It's not really cdefs-gcc.h. There's a lot of clang-isms that are also there that gcc has picked up in latter day versions of gcc too.

Basically, unless I can test the !GNUC case, I'm not going to do a !GNUC case. It's a waste of time unless there's a use case that actually uses it. In all cases that I can think of or test, GNUC will be defined. I am open to learning where my thinking might be blind, though.

Having said that, the file still support the different generations of the C language by defining things correctly for K&R up through C11 (and maybe newer). I do think that's important because the different compilers can and do compiler for different language constructs, as well as working for C and C++ in all their different variations.

[kib]

In D26818#598251, @imp wrote:

In D26818#598049, @kib wrote:

In D26818#598018, @imp wrote:

In D26818#597997, @kib wrote:

In fact having gnuc-isms clearly marked is a useful feature.

Everything in this file is a gnu ism... no?

No, I do not view it this way. First, there is enough stuff not related to GNU C extensions. Starting from the compat shims for c89 or even K&R (but some stuff like static assert or array sizing in args, is really for c99), POSIX/XSI/BSD visibility macros, ending in thread-local shims etc that do not require gnu-isms.

Do you have a compiler I can test whatever I come up with then? I don't mean to be difficult, but if there's no way to test it, there's no way to know if the ancient stuff even works.

What do you refer above as an ancient stuff ? Except for __P() and perhaps __inline/__const/__volatile everything else is not about ancient. [We should get rid of __inline/__const etc IMO].

Namespace visibility macros is actively used important feature, and it is sad situation that FreeBSD effectively stopped carrying about versioning them after around SUSv4 (I believe it is year 2008). But fixing this requires much more acquaintance with POSIX than e.g. I have. Users depend on them, we get bug reports, and I try to fix what is reported.

Then, there is relatively small core stuff that almost consistently marked with GNUC or guarded by global define (e.g. GNUCLIKE_ASM). The rest is built on top of these wrapped gnu-isms.

I was surprised to remind myself that we even care to wrap _compiler_member() with ifdef GNU_C.

May be it would be fine to do the stripping that you propose, but move affected cdefs.h into cdefs-gcc.h and have cdefs.h

#ifdef __GNUC__
#include <sys/cdefs-gcc.h>
#endif

keeping e.g. posix visibility maze of defines in cdefs.h.

I really dislike this idea. GNUC has sadly become standardized in all compilers that want to be taken seriously, so it's lost a lot of its original specialness.

I do not object that, and I do not propose to even try to add support for non-GNU-C compatible compilers in this change. I still think that structuring the header in a way that shows that FreeBSD tries to care, is useful, even if only as a declaration of intent.

Also please note that base headers need not only support compilation of base, but also work as the system headers when compiling third-party programs on FreeBSD. There were at least pcc (revived S.C. Johnson compiler, effectively dead again) and tcc (Fabrice Bellard, qemu) which seems to be quite alive.

It's not really cdefs-gcc.h. There's a lot of clang-isms that are also there that gcc has picked up in latter day versions of gcc too.

I am curious what do you refer to there. I can only think about __has_feature() from this file, but I do not think that gcc picked it.

Basically, unless I can test the !GNUC case, I'm not going to do a !GNUC case. It's a waste of time unless there's a use case that actually uses it. In all cases that I can think of or test, GNUC will be defined. I am open to learning where my thinking might be blind, though.

I do not propose to add anything for !GNUC, I only propose to structure it in a way that would not make an impression that we oppose anything !GNUC. There is nothing to test for !GNUC case in base.

Having said that, the file still support the different generations of the C language by defining things correctly for K&R up through C11 (and maybe newer). I do think that's important because the different compilers can and do compiler for different language constructs, as well as working for C and C++ in all their different variations.

It is not about compilers, but again a direct user feature. If somebody compiles third-party code on FreeBSD with specific selection of the C language standard (gcc/clang -std=XXX), our base headers should support the corresponding dialect, even if clang/gcc itself is latest and greatest.

[imp]

Don't go this far yet. Some of these are used elsewhere and we need some support for them to work with !GNU supporting compilers.
tcc is the only one that I know of, and it's been broken for some time.