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

On Feb  9 19:53, Corinna Vinschen wrote:
> 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___?

Btw., I don't quite understand the complexity of the int_fastN_t
definitions.  Do we *really* strill support a compiler which does
NOT define __INT_FASTn_TYPE__ / __UINT_FASTn_TYPE__?


Corinna