Re: [PATCH v0 0/2] Add C23 stdbit.h functions

OK. It was rejected as I wasn't subscribed. Resent after subscribing
and they now are in the cygwin-patches archive.

Thanks.

--joel

On Wed, Apr 8, 2026 at 10:16 AM Joel Sherrill <[email protected]>
wrote:

> I submitted a patch to cygwin-patches. I do not see it in the archives
> at https://cygwin.com/pipermail/cygwin-patches/2026q2/date.html.
> If it is caught at the moderator, please let it go through.
>
> Thanks.
>
> --joel
>
> On Tue, Apr 7, 2026 at 5:22 PM Joel Sherrill <[email protected]>
> wrote:
>
>> Looking closer, these are not coming from the "OS's" limits.h.
>> They are defined by GCC's limits.h. I checked an older RTEMS
>> toolchain to see how far back these were present. These are
>> not a recent addition.
>>
>> lib/gcc/sparc-rtems6/13.3.0/include/limits.h
>> lib/gcc/microblaze-rtems6/12.4.1/include-fixed/limits.h
>>
>> On my freshly updated Cygwin, I found that the gcc install included
>> a similar limits.h with ULLONG_WIDTH defined. So it is there but
>> not via the Cygwin limits.h.
>>
>> lib/gcc/x86_64-pc-cygwin/13/include/limits.h:# define ULLONG_WIDTH
>> __LONG_LONG_WIDTH__
>>
>> The problem appears to be that the Cygwin specific limits.h is
>> missing this code fragment that the RTEMS limits.h has.
>>
>> #ifndef _GCC_LIMITS_H_  /* if we have not seen gcc's limits.h yet */
>> #include_next <limits.h>
>> #endif
>>
>> But Cygwin's limits.h has its own defines for constants GCC's limits.h
>> provides which leads me to believe that Cygwin wants its limits.h to
>> be self-contained and not rely on GCC's. GCC's limits.h has a block
>> which defines all the _WIDTH constants like this:
>>
>> #if (defined __STDC_WANT_IEC_60559_BFP_EXT__ \
>>      || (defined (__STDC_VERSION__) && __STDC_VERSION__ > 201710L))
>> /* TS 18661-1 / C2X widths of integer types.  */
>> # undef CHAR_WIDTH
>> # define CHAR_WIDTH __SCHAR_WIDTH__
>> .... redacted
>> # undef ULLONG_WIDTH
>> # define ULLONG_WIDTH __LONG_LONG_WIDTH__
>> #endif
>>
>> I can add all of that to the Cygwin limits.h as a single block and
>> submit a patch. Is that an acceptable solution?
>>
>> Also I have no way of testing this. I can submit an untested patch.
>> Is that really OK?
>>
>> I don't mind doing this. But submitting untested patches
>> makes me uncomfortable. Is someone willing to test this?
>>
>> --joel
>>
>> On Tue, Apr 7, 2026 at 10:57 AM Corinna Vinschen <[email protected]>
>> wrote:
>>
>>> On Apr  3 17:08, Brian Inglis wrote:
>>> > On 2026-04-03 11:14, Joel Sherrill wrote:
>>> > > Sorry for the delay. I got back to Corrina's comment:
>>> > >
>>> > >  > No, they are not.  Target was Cygwin with its own limits.h, but
>>> even in
>>> > >  > newlib's limits.h, these WIDTH macros are not defined.
>>> Incidentally,
>>> > >  > they are not defined anywhere in the newlib-cygwin repo.  If this
>>> works
>>> > >  > for you, you're probably overloading the newlib headers with rtems
>>> > >  > headers.
>>> > >
>>> > > RTEMS does indeed have its own limits.h. And it must be aligned
>>> with  C23.
>>> > >
>>> > > And Cygwin has its own limits.h which has not been updated to have
>>> any of
>>> > > the new C23 constants. Four show up in compiler error messages
>>> building
>>> > > the stdbit code.
>>> > >
>>> > > https://en.cppreference.com/w/c/header/limits.html
>>> > > <https://en.cppreference.com/w/c/header/limits.html>
>>> > >
>>> > > The stdbit.h addition needs a limits.h with the C23 constants.
>>> > >
>>> > > Can those be added to the Cygwin limits.h? Then we can proceed with
>>> > > the stdbit.h addition.
>>> >
>>> > For fastest response, please submit a patch with subject like:
>>> >
>>> > [PATCH] Cygwin: winsup/cygwin/include/limits.h: Add C23 ..._WIDTH
>>> definitions
>>> >
>>> > similar to your RTEMS changes, using normal feature test macros as
>>> > appropriate, with git format-patch & git send-email to:
>>> >
>>> > Cygwin core component patch submission and discussion
>>> >                                               <
>>> [email protected]>
>>>
>>> Either that (patches are always welcome), or just use the
>>> compiler-provided constants.
>>>
>>>
>>> Thanks,
>>> Corinna
>>>
>>