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

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
>>
>