Cygwin is not part of newlib - newlib is used as libc by Cygwin, so adjustments
have to be made solely within newlib, to support allowing each environment and
system to define their own time bases, depending on the platform capabilities
under libc/machine/ and their BSPs under libgloss/.
Patches for Cygwin have to be submitted to [email protected] instead,
and justified solely on the impact to the emulation environment hosted under the
Windows platform, supported by Mingw64 cross-tools.
On 2025-06-22 12:14, Mazen Adel wrote:
> 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 <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 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
>
--
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.