Re: /usr/include/stdatomic.h is not self-contained (fwd from Cygwin list)

On Feb  9 17:39, Hans-Bernhard Bröker wrote:
> Am 09.02.2026 um 15:38 schrieb Corinna Vinschen:
> 
> > Therefore we either have to include stdint.h from stdatomic.h, as
> > Tomohiro suggested, or we have to rearrange the headers slightly
> > and move the FAST definitions into machine/_default_types.h.
> 
> I'm not sure if this has changed over the years (decades, even), but the
> stance of the C Standard community always used to be that no standard header
> may ever include any of the others, nor define any things only specified to
> be defined by others than itself.
> 
> So in theory it should be allowed to define your own things named, say,
> uint16_t, in any source code that does not #include <stdint.h>, without
> clashing with the standard's definitions.  I.e. code that begins something
> like
> 
> #include <stdatomic.h>
> typedef unsigned char uint8_t;
> 
> must not be flagged for a redefinition of uint8_t.  Identifiers with
> external linkage (i.e. variables and functions) are allowed to cause such a
> clash, typedefs and macros are not.
> 
> See C99 7.1.3p1, where it uses the phrase "if any of its associated headers
> is included"

Our stdatomic.h already falls flat in terms of this, in contrast to
the FreeBSD original using the underscored versions of these types.

As I wrote, we can already easily use the underscored LEAST types,
just the FAST types have to be defined as underscored types in
machine/_default_types.h as well.

Strange enough our stdatomic.h also uses ptrdiff_t and wchar_t, both of
which (I realize this for the first time in fact) don't have underscored
versions either.  Maybe we should go ahead and, apart from the stdint.h
FAST types, we should also define __wchar_t and __ptrdiff_t in
machine/_default_types.h based on the definitions __PTRDIFF_TYPE__ and
__WCHAR_TYPE___?


Corinna