On 2025-05-01 06:29, Christian Franke wrote:
Jon Turney wrote:
On 30/04/2025 12:33, Christian Franke wrote:
Christian Franke wrote:
Jon Turney wrote:
On 28/04/2025 16:43, Christian Franke wrote:
A followup to:
https://sourceware.org/pipermail/cygwin-patches/2025q2/013678.html
Thanks!
The SUS page for clock_settime() contains the following text:
[EINVAL]
The tp argument specified a nanosecond value less than zero or greater
than or equal to 1000 million.
... so if we're going to validate tv_nsec, it seems that's the range to use
Yes. The patch only checks the lower bound because the upper bound is
already correctly checked later in settimeofday().
This is just prompts me to further questions: Is settimeofday() specified to
permit some kinds of non-normalized values?
settimeofday() is not part of POSIX, Linux settimeofday(2) only says:
"
EINVAL
Timezone (or something else) is invalid.
"
Our std-...xml docs say BSD, and Free/NetBSD say BSD 4.2, with timezone ignored
and set to zeros since 4.4.
They are also in SunOS/Solaris, HP-UX, Darwin, CentOS/RHEL, Debian, and likely
AIX and OSF/1 aka Tru64.
Free/NetBSD [gs]ettimeofday(2) say:
RETURN VALUES
Upon successful completion, the value 0 is returned; otherwise the value -1
is returned and the global variable errno is set to indicate the error.
ERRORS
The following error codes may be set in errno:
[EINVAL] The supplied timeval value is invalid.
[EPERM] A user other than the super‐user attempted to set the time.
--
RETURN VALUES
A return value 0 indicates that the call succeeded. A return value -1
indicates an error occurred, and in this case an error code is stored into the
global variable errno.
ERRORS
The following error codes may be set in errno:
[EFAULT] An argument address referenced invalid memory.
[EPERM] A user other than the super user attempted to set the
time, or the specified time was less than the current time, which was not
permitted at the current security level.
These sys/time.h docs specify struct timeval since the Epoch, as do
clock_[gs]ettime struct timespec, and imply only positive values, probably with
us/ns value limits, as they are expected to be running system clock values.
It is also usually missing in the docs that negative time_t values are accepted
by gmtime() etc. This works on Cygwin and Debian:
The TZ, C, and POSIX time.h docs with time_t/struct tm interfaces support a wide
range of years defined in TZ to be +/-2^59s > Big Bang ~13.82Gyr.
--
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
