C11 conformance: <uchar.h>, TIME_UTC, timespec_get

[Pavel M]

Thanks.

To remind: from Cygwin FAQ
<https://www.cygwin.com/faq.html#faq.programming.glibc>:
> Where is glibc?
> Cygwin does not provide glibc. It uses newlib instead, which provides
much (but not all)
> of the same functionality. Porting glibc to Cygwin would be difficult.

I didn't know that newlib is a freestanding implementation.

OK, I'll try to mitigate using libicu-devel, etc.

On Tue, 10 May 2022 at 20:17, Brian Inglis <Brian.Inglis@systematicsw.ab.ca>
wrote:

> On 2022-05-10 09:35, Pavel M wrote:
> > Hi all,
> > Any updates?
>
> Nobody else has noticed or mentioned those in the last decade, so there
> may not be, as volunteers have limited time and their own interests and
> priorities.
>
> Given that newlib is a freestanding implementation, and gcc does not
> provide that header, those definitions or declarations, these are
> considered platform implementation issues, which someone supporting that
> platform has to decide if they will provide and support.
>
> ICU provides uchar.h which Cygwin libicu-devel maintainer installs under
> /usr/include/unicode/ with Unicode licence under
> /usr/share/icu/<VERSION>/LICENSE.
> You could pull those two files from the ICU distro for use in your work.
>
> It also is/will be available on glibc platforms which support it.
> Remember that GNU products are GPL licensed with possibly undesirable
> requirements for most commercial products.
>
> Similarly, TIME_UTC may not be available on some newlib
> platforms/targets, so it will be up to platform and/or target
> maintainers to decide if they can support it, and provide implementations.
>
> I don't know what your host platform is, your newlib target, or what
> POSIX time.h CLOCK_/clock_... support is available, but you may wish to
> use that instead, until someone can provide the ISO C equivalent in
> newlib under a BSD licence.
>
> You may also wish to look at what is available in *BSD sources.
>
> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
> [Data in binary units and prefixes, physical quantities in SI.]
>