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

On Feb  9 20:13, Corinna Vinschen wrote:
> 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...

I pushed a couple of patches to pull this straight.  Mainly we now
have the definition of __{u}int_fastN_t types in machine/_default_types.h,
as well as definitions of __wchar_t and __ptrdiff_t and the definition
of __ISO_C_VISIBLE for ISO C23 ialigned to FreeBSD to simplify porting
FreeBSD headers.  For a start, the stdatomic.h header is now verbatim
FreeBSD.

Please give it a try.


Thanks,
Corinna