On Mon, 30 Jan 2023 14:54:39 +0100, Alejandro Colomar wrote:
On 1/30/23 14:50, G. Branden Robinson wrote:
At 2023-01-30T14:15:50+0100, Alejandro Colomar wrote:
On 1/30/23 08:08, Jakub Wilk wrote:
* Alejandro Colomar <alx.manpages@xxxxxxxxx>, 2023-01-29 16:48:
+.BR " /*\(da*/ tv_nsec;" " /* Nanoseconds [" 0 ", " 999999999 "] */"
Please make it
/* see below */ tv_nsec
or maybe
long /* but see below */ tv_nsec
(given that C23 is not a thing yet).
The reason why I seriously considered /*↓*/ is that it is a bit
shocking to the reader, which will prompt it to read the rest of the
page to see what the hell that is.
Even more shocking will be 'v', which is what it will degrade to on
ASCII, ISO 8859, and code page 1047 terminals. On top of being
startling, it will look simply like an error.
I'm worried that if we make it `long` plus a comment to see below,
many will ignore it.
That's on them. "/* see below */" means what it says. A person cannot
reasonably claim they weren't warned.
I think
long /* see below */ tv_nsec;
meets the requirements at issue.
The last POSIX 202x Issue 8 Draft 2.1 2021-08 says under B.2.8.5 Clocks and
Timers - • Data Definitions for Clocks and Timers from lines numbered 121835ff:
"Time values are represented in the timespec structure.
The tv_sec member is of type time_t so that this member is compatible
with time values used by POSIX.1 functions and the ISO C standard.
The tv_nsec member is a *signed long* in order to simplify and clarify
code that decrements or finds differences of time values.
Note that because 1 billion (number of nanoseconds per second) is less
than half of the value representable by a signed 32-bit value, it is
always possible to add two valid fractional seconds represented as
integral nanoseconds without overflowing the signed 32-bit value."
and other mentions repeat its 32-bitness, disallow values < 0 or >= 1Mi, laud
simplicity of arithmetic, and eschew binary fraction representations!
More recent discussions about implementation-defined type start from the
publicly available archive and mention N2878:
https://www.mail-archive.com/austin-group-l%40opengroup.org/msg09706.html
with replies:
"The Linux issue raised there has been discussed here in the past (2014) and was
considered simply a bug that either glibc or the kernel should fix."
"(There are other reasons why the motivation for the change seems weak, such as
that the primary motivating example given is to facilitate working around a
Linux kernel issue that was fixed five years ago.)"
"...suggestion that perhaps changing this type might be acceptable is being
taken as approval from the AG that such a change should go into C2x. ..., I
propose to refute this during the upcoming ballot resolution meeting unless
someone can persuade me I'm wrong!"
"In any case, if C23 changes it to nsec_t and we decide we want it to remain a
long in POSIX, we can simply require that nsec_t is defined as a long in Issue 9."
"If that's the proposal, then I agree with you, that's relatively harmless for
POSIX code (slightly more difficult for strict C code, and they should certainly
be adding a PRI macro to inttypes.h - all invented printable types should have
at least one such a macro defined).
But if the proposal is to change it to int32_t (or worse uint32_t) then that
would be a real problem - despite 32 bits clearly being enough to represent a
count of nanoseconds within one second (had the tv_nsec field been defined that
way originally, that would have been OK, but it cannot be changed into that now)."
WG14 documents repeat the long-ness but have little discussion from 2011 drafts
until N2878 and N3066.
Perhaps some more discussion between committee members who are Linux
implementers and/or representatives on other/both standards bodies (e.g. liaison
Nick), could help resolve this discrepancy, before one gets frozen in a position
that some other can not conform to?
--
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 à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
