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

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
>