Re: [PATCH] libc: Add/Update prototypes For POSIX Issue 8 functions

Mazen Adel <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <CANjESSCKeuXhg9EPA1OW+gLStixDV4BhAFHG2V7mpX=ZMOG14w@mail.gmail.com>
Hello,

I previously submitted a patch to add timespec_get() to time.h.
Here is the link to the patch:
https://sourceware.org/pipermail/newlib/2025/021885.html.

I’ve now removed the TIME_UTC definition from cygwin/time.h to avoid
conflicts as discussed.

Is there anything else that needs to be changed concerning this function or
the other functions before the patch can move forward?

Best regards,
Mazen Adel
On Sun, Jun 22, 2025 at 8:34 AM Brian Inglis <
[email protected]> wrote:

> On 2025-06-21 15:34, Mazen Adel Elmessady wrote:
> ...> diff --git a/newlib/libc/include/time.h b/newlib/libc/include/time.h
> > index ab3491341..a2df4f7fd 100644
> > --- a/newlib/libc/include/time.h
> > +++ b/newlib/libc/include/time.h
> > @@ -57,6 +57,11 @@ clock_t       clock (void);
> >   double         difftime (time_t _time2, time_t _time1);
> >   time_t         mktime (struct tm *_timeptr);
> >   time_t         time (time_t *_timer);
> > +#if (__ISO_C_VISIBLE >= 2011 || __POSIX_VISIBLE >= 202405)
> > +#define TIME_UTC 1
> > +
> > +int        timespec_get(struct timespec *ts, int base);
> > +#endif
> >   #ifndef _REENT_ONLY
> >   char          *asctime (const struct tm *_tblock);
> >   char          *ctime (const time_t *_time);
> Shouldn't the time base TIME_... values depend on what is available and
> used by
> the implementation, environment, or operating system?
>
> For example, Cygwin already defines TIME_UTC in cygwin/time.h.
>
> Time base values such as TIME_UTC, TIME_TAI, TIME_LCL, TIME_ACTIVE,
> TIME_THREAD_ACTIVE, etc. could be valid.
>
> These MUST be defined in the same header where any other TIME_...
> constants are
> defined, as they MUST NOT have conflicting or overlapping values.
>
> See N3220 ISO/IEC 9899:2024 WD aka <wink> ISO/IEC 9899:2023 FDIS:
>
> 7.29.1 Components of time
> 2 ...
>          TIME_UTC
>          TIME_MONOTONIC
>    which expand to integer constants greater than 0 designating the
>    calendar time and monotonic time bases, respectively. Additional time
>    base macro definitions, beginning with TIME_ and an uppercase letter,
>    may also be specified by the implementation; and,
>          TIME_ACTIVE
>          TIME_THREAD_ACTIVE
>    which, if defined, expand to integer values, designating overall
>    execution and thread-specific active processing time bases,
>    respectively.
> 3 The definition of macros for time bases other than TIME_UTC are optional.
>    If defined, the corresponding time bases are supported by timespec_get
>    and timespec_getres, and their values are positive.
>    If defined, the value of the optional macro TIME_ACTIVE shall be
>    different from the constants TIME_UTC and TIME_MONOTONIC and shall not
>    change during the same program invocation.
>    The optional macro TIME_THREAD_ACTIVE shall not be defined if the
>    implementation does not support threads; its value shall be different
>    from TIME_UTC, TIME_MONOTONIC, and TIME_ACTIVE, it shall be the same
>    for all expansions of the macro for the same thread, and the value
>    provided for one thread shall not be used by a different thread as the
>    base argument of timespec_get or timespec_getres.
> ...
> 7.33.18 Date and time <time.h>
> 1 Macros beginning with TIME_ and an uppercase letter may be added to
>    the macros in the <time.h> header by a future revision of this
>    document or by an implementation.
> 2 The time bases TIME_MONOTONIC, TIME_ACTIVE and TIME_THREAD_ACTIVE may
>    become mandatory in future versions of this standard.
> ...
>
> NOTE: w32api-headers w32api/timezoneapi.h TIME_ZONE_... and other TIME_...
> constants and types may conflict with this spec in draft and future
> releases.
>
> --
> Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada
>
> La perfection est atteinte                   Perfection is achieved
> non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to
> add
> mais lorsqu'il n'y a plus rien à retrancher  but when there is no more to
> cut
>                                  -- Antoine de Saint-Exupéry
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.