Hi наб, On 1/29/23 17:31, наб wrote:
n3091 accepts n3066, making it part of the next working draft and C23: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3091.doc Update timespec.3type appropriately, largely mirroring my paper. Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@xxxxxxxxxxxxxxxxxx> --- man3type/timespec.3type | 47 +++++++++++++---------------------------- 1 file changed, 15 insertions(+), 32 deletions(-) diff --git a/man3type/timespec.3type b/man3type/timespec.3type index 7cd80ce86..37dc2da61 100644 --- a/man3type/timespec.3type +++ b/man3type/timespec.3type @@ -16,14 +16,28 @@ Standard C library .PP .B struct timespec { .BR " time_t tv_sec;" " /* Seconds */" -.BR " long tv_nsec;" " /* Nanoseconds [" 0 ", " 999999999 "] */" +.BR " /*\(da*/ tv_nsec;" " /* Nanoseconds [" 0 ", " 999\(aq999\(aq999 "] */" .B }; .EE .SH DESCRIPTION Describes times in seconds and nanoseconds. +.PP +.I tv_nsec +is of an implementation-defined signed type capable of holding the specified range.
Ahh, now I remember! I had something in mind this morning, that I forgot when writing the email.
The thing is, mathematically, the term for this would be interval, rather than range.
I started using it in the following code: <https://github.com/shadow-maint/shadow/pull/624#issuecomment-1384029138> <https://github.com/shadow-maint/shadow/pull/624/files#diff-de2f8567ced0ae94dd9c780a02947cda28a6adeb61c8cd75d1645c93567bcc6fR103> <http://www.alejandro-colomar.es/src/alx/alx/libc/libc-rand.git/tree/include/c/rand/csrand/csrand_uniform.h> Would you mind using interval here?
+Under glibc, this is usually +.IR long , +and +.I long long +on X32. +It can be safely down-cast to any concrete 32-bit integer type for processing. .SH STANDARDS C11 and later; POSIX.1-2001 and later. +.SH VERSIONS +Prior to C23, +.I tv_nsec +was +.IR long . .SH NOTES The following headers also provide this type: .IR <aio.h> , @@ -33,37 +47,6 @@ The following headers also provide this type: .IR <sys/select.h> , and .IR <sys/stat.h> . -.SH BUGS -Under glibc, -.I tv_nsec -is the -.I syscall -long, -though this affects only fringe architectures like X32, -which is ILP32, but uses the LP64 AMD64 syscall ABI. -In reality, the field ends up being defined as: -.PP -.in +4n -.EX -#if __x86_64__ && __ILP32__ /* == x32 */ - long long tv_nsec; -#else - long tv_nsec; -#endif -.EE -.in -.PP -This is a long-standing and long-enshrined glibc bug -.UR https://sourceware.org/bugzilla/show_bug.cgi?id=16437 -.I #16437 -.UE , -and an incompatible extension to the standards; -however, as even a 32-bit -.I long -can hold the entire -.I tv_nsec -range, -it's always safe to forcibly down-cast it to the standard type.
If the C standards and POSIX don't want to add a type for it, let us disagree with their decission.
Let's add a bug:There's no portable way to declare to pointer to tv_nsec, since you never know for sure if it will be long* or llong*.
Do you agree? Cheers, Alex
.SH SEE ALSO .BR clock_gettime (2), .BR clock_nanosleep (2),
-- <http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
