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

On 2026-02-12 13:43, Corinna Vinschen wrote:
> 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.

Do we really need to maintain these when gcc already provides them?

$ wc -l /lib/gcc/x86_64-pc-cygwin/13/include/std{int{-gcc,},atomic}.h
    14 /lib/gcc/x86_64-pc-cygwin/13/include/stdint.h
   369 /lib/gcc/x86_64-pc-cygwin/13/include/stdint-gcc.h
   255 /lib/gcc/x86_64-pc-cygwin/13/include/stdatomic.h

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher  but when there is no more to cut
                                 -- Antoine de Saint-Exupéry