Re: [PATCH v2 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: 3444 bytes --]

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@nabijaczleweli.xyz>
> ---
>   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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]