Moving C11 Functions from winsup to newlib

[Joel Sherrill]

On Mon, Mar 17, 2025 at 1:18 PM Corinna Vinschen <vinschen@redhat.com>
wrote:

> On Mar 17 09:48, Joel Sherrill wrote:
> > Thanks. Sounds like moving the uchar.h file is a good idea. But newlib
> will
> > need its
> > own more flexible implementation.
>
> Exactly.
>
> > What about the C11 function timespec_get? Cygwin has the obvious
> > implementation. Should that just go in time/?
>
> Sure, no worries.  However, not yet.  We're working on the Cygwin 3.6
> release, and I would prefer if we do a function and header reshuffle
> only after we cut the 3.6 branch.
>

Gotcha. This is preparing for potential Google Summer of Code work.
These looked to be the easiest to address.

For RTEMS, I'd rather see the new POSIX Issue 8 methods like
pthread_mutex_clocklock()  get added but ultimately, we want better
C11 support also.

Any thoughts on the Annex K optional Bounds-checking interfaces?
I haven't done a lot of research on implementations but there is this
one: https://github.com/sbaresearch/slibc

--joel


>
> Thanks,
> Corinna
>
>
> >
> > Thanks.
> >
> > --joel
> >
> > On Mon, Mar 17, 2025 at 5:55 AM Corinna Vinschen <vinschen@redhat.com>
> > wrote:
> >
> > > Hi Joel,
> > >
> > > On Mar 14 11:53, Joel Sherrill wrote:
> > > > Hi
> > > >
> > > > In looking at what's missing from RTEMS for C11, I noticed that these
> > > from
> > > > uchar.h are in winsup (as .cc) but not in newlib.
> > > >
> > > > size_t c16rtomb(char *restrict, char16_t, mbstate_t *restrict);
> > > > size_t c32rtomb(char *restrict, char32_t, mbstate_t *restrict);
> > > > size_t mbrtoc16(char16_t *restrict, const char *restrict, size_t,
> > > mbstate_t
> > > > *restrict);
> > > > size_t mbrtoc32(char32_t *restrict, const char *restrict, size_t,
> > > mbstate_t
> > > > *restrict);
> > > >
> > > > Would it be ok to move them to the newlib side?
> > >
> > > We can move the uchar.h header to newlib verbatim, it's target
> > > independent.
> > >
> > > It's not as easy for the actual implementation, because Cygwin's
> > > implementation relies on char16_t being equivalent to wchar_t as Cygwin
> > > uses the Windows UTF-16 as wchar_t type for simplicity.
> > >
> > > A truly independent implementation must not rely on wchar_t being any
> > > Unicode variation, be it UCS-2, UTF_16, or UTF-32.
> > >
> > > Some systems have their own wchar_t, as with the historical
> > > implementations of wchar_t in newlib/libc/ctype/jp2uc.c for japanese
> > > codesets (S)JIS/EUCJP.
> > > We should probably get rid of them in favor of true wchar_t == "Some
> > > Unicode" for *all* targets.
> > >
> > > > Add a uchar directory? Or where?
> > >
> > > Either that, or in string.
> > >
> > > > What about converting the implementation to C? Is that needed?
> > >
> > > The Cygwin functions are plain C. They are just inside a C++ source.
> > >
> > >
> > > Corinna
> > >
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/newlib/attachments/20250317/84dc0662/attachment.htm>