struct timespec and tv_nsec

[Andrew Josey]

This did not make it to the list…

Subject: struct timespec and tv_nsec
Date: 29 May 2014 01:35:19 BST
X-Diagnostic: Not on the accept list
Hello,
In the Linux world the definition of struct timespec has recently been a
source of controversy.
Specifically, struct time*val* has an abstract type for the tv_usec
field (suseconds_t), whereas struct time*spec* is defined to use "long".
This turns out to cause some serious complexity for the case of a 64-bit
kernel servicing a 32-bit (ILP32LL64) ABI that wants to support a 64-bit
time_t to avoid the Y2038 problem.
Although 64 bits for the tv_nsec member doesn't buy anything, it also
generally doesn't cost anything since the structure will naturally be
padded out to 128 bits for alignment.
The "obvious" hack around of introducing a padding member would still
mean that the kernel would have to consider the case of garbage in that
padding member, which makes the behavior inconsistent with the 64-bit
native ABI.
When this was originally debated in 2011, Linus Torvalds came down very
strongly on ignoring the letter of the current standard and follow the
technically more desirable solution.
As such, it would be desirable to introduce an snseconds_t abstract data
type. I don't know if this is still under Austin Group purview or if
this is now a C standards issue...
-hpa

--------
Andrew Josey The Open Group
Director, Standards Apex Plaza, Forbury Road
Email: a.josey-7882/***@public.gmane.org Reading,Berks.RG1 1AX,England
Tel:[phone] US fax: [phone]
Mobile:[phone] UK fax: [phone]

The Open Group Boston 2014, July 21-22
http://www.opengroup.org/events

ArchiMate, DirecNet, Jericho Forum, Making Standards Work, OpenPegasus, The Open Group, TOGAF, and UNIX are registered trademarks and Boundaryless Information Flow, Dependability Through Assuredness, FACE, Open Platform 3.0, and The Open Group Certification Mark are trademarks of The Open Group.

[Geoff Clare]

Subject: struct timespec and tv_nsec
Date: 29 May 2014 01:35:19 BST
X-Diagnostic: Not on the accept list

[...]

Specifically, struct time*val* has an abstract type for the tv_usec
field (suseconds_t), whereas struct time*spec* is defined to use "long".

[...]

As such, it would be desirable to introduce an snseconds_t abstract data
type. I don't know if this is still under Austin Group purview or if
this is now a C standards issue...

C11 requires tv_nsec to be type long, which means that if we change
it to be a new snseconds_t type in Issue 8, we would have to require
that snseconds_t is defined as long in order not to conflict with C11.

So yes, it's a C standards issue.

[Rich Felker]

Post by Geoff Clare

Subject: struct timespec and tv_nsec
Date: 29 May 2014 01:35:19 BST
X-Diagnostic: Not on the accept list

[...]

Specifically, struct time*val* has an abstract type for the tv_usec
field (suseconds_t), whereas struct time*spec* is defined to use "long".

[...]

As such, it would be desirable to introduce an snseconds_t abstract data
type. I don't know if this is still under Austin Group purview or if
this is now a C standards issue...

C11 requires tv_nsec to be type long, which means that if we change
it to be a new snseconds_t type in Issue 8, we would have to require
that snseconds_t is defined as long in order not to conflict with C11.
So yes, it's a C standards issue.

This is just a linux kernel bug which needs to be fixed. They have a
number of other such bugs in x32 too. It's possible to work around it
in userspace on the library side (we do this in musl libc) but it's a
bit costly/painful and glibc does not do so yet. There's an open bug
for it which I filed:

https://sourceware.org/bugzilla/show_bug.cgi?id=16437

And another bug filed for related issues:

https://sourceware.org/bugzilla/show_bug.cgi?id=16438

Rich