Re: [PATCH 1/3] timespec.3type: tv_nsec is impl-def-type, glibc llong not a bug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux