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

On Feb  9 20:03, Corinna Vinschen wrote:
> 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__?

I just asked Google Gemini and it claims that gcc introduced these
types with gcc 4.5.0 in 2010, and clang with version 2.9 in 2011,
together with __INT_LEASTn_TYPE__.

So I really wonder why we handle the FAST types differently from the
way we handle the LEAST types...


Corinna