Re: Moving C11 Functions from winsup to newlib
Joel Sherrill <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <CAF9ehCUdh3KDK6_7itMP+RaQy9dFeJMtMVzKKoacBf8VZO4e7g@mail.gmail.com> |
Thanks. Sounds like moving the uchar.h file is a good idea. But newlib will need its own more flexible implementation. What about the C11 function timespec_get? Cygwin has the obvious implementation. Should that just go in time/? Thanks. --joel On Mon, Mar 17, 2025 at 5:55 AM Corinna Vinschen <[email protected]> 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 > >