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

[Alejandro Colomar <alx.manpages@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3440 bytes --]

Hey наб!

On 1/28/23 15:17, наб 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.
Nice! :-)

> 
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> ---
> This is in many ways a followup to the patchset that originally added
> the BUGS sexion to timespec.3type, root msgid of
>    <ec1dcc655184f6cdaae40ff8b7970b750434e4ef.1638123425.git.nabijaczleweli@nabijaczleweli.xyz>
> 
> For ease of reference, n3066:
>    https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3066.pdf
> and the relevant part of n3091 (screenshot, it's a .doc):
>    https://cohost.org/nabijaczleweli/post/922578-pog-pog

What happened in the end with nsec_t?  Was it rejected, or are they still 
considering it?

> 
> 2/3 and 3/3 only span the pages that matched git grep -l tv_nsec,
> but that should be most of the relevant ones
> 
>   man3type/timespec.3type | 46 +++++++++++++----------------------------
>   1 file changed, 14 insertions(+), 32 deletions(-)
> 
> diff --git a/man3type/timespec.3type b/man3type/timespec.3type
> index 7cd80ce86..ca5533814 100644
> --- a/man3type/timespec.3type
> +++ b/man3type/timespec.3type
> @@ -16,14 +16,27 @@ 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 ", " 999999999 "] */"

I'm tempted to merge this patch.  It's sooo qute /*↓*/

Please use the digit separator \(aq for the big number.

>   .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.
> +Under glibc, this is usually
> +.IR long ,
> +and
> +.I long long
> +on X32.
> +It can safely be down-cast to any concrete 32-bit integer type for processing.

Ok.

>   .SH STANDARDS
>   C11 and later;
>   POSIX.1-2001 and later.
> +Prior to C23

A comma here?

> +.I tv_nsec
> +was
> +.IR long .

Please move this to a new VERSIONS sexion.

>   .SH NOTES
>   The following headers also provide this type:
>   .IR <aio.h> ,
> @@ -33,37 +46,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.

Ok.

Cheers,

Alex

>   .SH SEE ALSO
>   .BR clock_gettime (2),
>   .BR clock_nanosleep (2),

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]