sys/types.h: Define new types: [s]nseconds_t
Checks
Context |
Check |
Description |
dj/TryBot-apply_patch |
success
|
Patch applied to master at the time it was sent
|
dj/TryBot-32bit |
success
|
Build for i686
|
Commit Message
For symmetry with the existing [s]useconds_t types.
The timespec(3) structure uses long for tv_nsec,
except if __x86_64__ && __ILP32__,
in which case it uses long long.
Let's define a stable type that can be relied upon by users,
for example for creating pointers.
Cc: наб <nabijaczleweli@nabijaczleweli.xyz>
Cc: Jakub Wilk <jwilk@jwilk.net>
Cc: Zack Weinberg <zackw@panix.com>
Cc: Stefan Puiu <stefan.puiu@gmail.com>
Cc: Michael Kerrisk (man-pages) <mtk.manpages@gmail.com>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
---
posix/sys/types.h | 8 ++++++++
1 file changed, 8 insertions(+)
Comments
On Dez 07 2021, Alejandro Colomar via Libc-alpha wrote:
> diff --git a/posix/sys/types.h b/posix/sys/types.h
> index 477a45f4af..147e2d3500 100644
> --- a/posix/sys/types.h
> +++ b/posix/sys/types.h
> @@ -140,6 +140,14 @@ typedef __suseconds_t suseconds_t;
> # endif
> #endif
>
> +#if defined __x86_64__ && defined __ILP32__
> +typedef unsigned long long nseconds_t;
> +typedef long long snseconds_t;
> +#else
> +typedef unsigned long nseconds_t;
> +typedef long snseconds_t;
> +#endif
This needs to be defined in terms of a type defined in a bits header.
Andreas.
On Tue, Dec 07, 2021 at 12:19:58PM +0100, Alejandro Colomar wrote:
> For symmetry with the existing [s]useconds_t types.
If you'd hold on to your horses, like, until the next WG14 meeting,
turns out I know a guy who knows a guy, but my guy is the WG14 project
editor, and I'm like, a day's away from getting an N number and turns
out getting your "C defect" paper through is pretty easy if you don't
have to sit in an NB meeting yourself.
(Granted, this wouldn't have to be a paper at all if this were C++,
but this is pretty good as-is.)
You can find my current draft:
https://srhtcdn.githack.com/~nabijaczleweli/wg14/blob/868d3e096db0fe4378d77cd67215bed56045196d/N%3F%3F%3F%3F.pdf
accepting this would mean just a
typedef decltype(struct timespec::tv_nsec) nsec_t;
to make the implementation C2X conformant again.
Best,
On Tue, Dec 7, 2021, at 6:19 AM, Alejandro Colomar wrote:
> For symmetry with the existing [s]useconds_t types.
>
> The timespec(3) structure uses long for tv_nsec,
> except if __x86_64__ && __ILP32__,
> in which case it uses long long.
> Let's define a stable type that can be relied upon by users,
> for example for creating pointers.
I endorse the _concept_ of this change, regardless of whether the POSIX and C committees like it. That said, there are some technical issues with the patch as is:
> +#if defined __x86_64__ && defined __ILP32__
> +typedef unsigned long long nseconds_t;
> +typedef long long snseconds_t;
> +#else
> +typedef unsigned long nseconds_t;
> +typedef long snseconds_t;
> +#endif
As Andreas pointed out, this belongs in bits/types.h, defining __nseconds_t and __snseconds_t. Also, the choice of underlying type should be controlled by a new macro defined by bits/wordsize.h, so that we don't have x86-specific ifdeffage in bits/types.h.
There should then be headers <bits/types/nseconds_t.h> and <bits/types/snseconds_t.h> that define the user-namespace typedefs in terms of the __-prefixed types. <bits/types/struct_timespec.h> should include <bits/types/snseconds_t.h> and use __snseconds_t (*not* snseconds_t) in the definition of struct timespec; <sys/types.h> should include both headers.
See if you can clean up the ifdef mess in the definition of struct timespec at the same time. It appears to me, just looking at that, that this is *not* just an issue for x86-64 with the x32 ABI.
Tangentially, should we actually have nseconds_t if nothing's going to use it?
zw
Hi наб,
On 12/7/21 14:17, наб wrote:
> On Tue, Dec 07, 2021 at 12:19:58PM +0100, Alejandro Colomar wrote:
>> For symmetry with the existing [s]useconds_t types.
> If you'd hold on to your horses, like, until the next WG14 meeting,
> turns out I know a guy who knows a guy, but my guy is the WG14 project
> editor, and I'm like, a day's away from getting an N number and turns
> out getting your "C defect" paper through is pretty easy if you don't
> have to sit in an NB meeting yourself.
> (Granted, this wouldn't have to be a paper at all if this were C++,
> but this is pretty good as-is.)
Sounds great! :)
I'll continue with my glibc patch as a draft, to learn how glibc types
are defined (there's a lot of magic I still need to learn), but will
wait for the results of your C2X proposal before merging this to glibc.
As Zack suggested, an unsigned version is probably unnecessary, so I'll
use nsec_t for the patches, as you used in your draft. I like short
names, and also signed types.
>
> You can find my current draft:
> https://srhtcdn.githack.com/~nabijaczleweli/wg14/blob/868d3e096db0fe4378d77cd67215bed56045196d/N%3F%3F%3F%3F.pdf
It looks good.
Would you mind sharing the source code of your pdf? I'm curious to
learn to write those papers.
Also, please CC me when you have any news on that :)
> accepting this would mean just a
> typedef decltype(struct timespec::tv_nsec) nsec_t;
> to make the implementation C2X conformant again.
Hmm, not sure if it would be better for glibc to define nsec_t in terms
of timespec, or the other way around. I had in mind something like the
following:
Here would go many ifdefs:
typedef /* probably */ long nsec_t;
And this would be clean:
struct timespec {
...
nsec_t tv_nsec;
};
Thanks,
Alex
Hi Zack,
On 12/7/21 16:50, Zack Weinberg wrote:
> On Tue, Dec 7, 2021, at 6:19 AM, Alejandro Colomar wrote:
>> For symmetry with the existing [s]useconds_t types.
>>
>> The timespec(3) structure uses long for tv_nsec,
>> except if __x86_64__ && __ILP32__,
>> in which case it uses long long.
>> Let's define a stable type that can be relied upon by users,
>> for example for creating pointers.
>
> I endorse the _concept_ of this change, regardless of whether the POSIX and C committees like it. That said, there are some technical issues with the patch as is:
:)
>
>> +#if defined __x86_64__ && defined __ILP32__
>> +typedef unsigned long long nseconds_t;
>> +typedef long long snseconds_t;
>> +#else
>> +typedef unsigned long nseconds_t;
>> +typedef long snseconds_t;
>> +#endif
>
> As Andreas pointed out, this belongs in bits/types.h, defining __nseconds_t and __snseconds_t. Also, the choice of underlying type should be controlled by a new macro defined by bits/wordsize.h, so that we don't have x86-specific ifdeffage in bits/types.h.
>
> There should then be headers <bits/types/nseconds_t.h> and <bits/types/snseconds_t.h> that define the user-namespace typedefs in terms of the __-prefixed types. <bits/types/struct_timespec.h> should include <bits/types/snseconds_t.h> and use __snseconds_t (*not* snseconds_t) in the definition of struct timespec; <sys/types.h> should include both headers.
>
> See if you can clean up the ifdef mess in the definition of struct timespec at the same time. It appears to me, just looking at that, that this is *not* just an issue for x86-64 with the x32 ABI.
Thanks for the directions. This way it'll be much easier. I'll try to
have a look at that mess ;)
>
> Tangentially, should we actually have nseconds_t if nothing's going to use it?
>
Hmmm, I think we can live with a single ns type. I like signed types,
so if nothing is using the unsigned version, we can live without it.
I'll use the nsec_t name, as proposed by наб, for the moment.
Cheers,
Alex
On Tue, 7 Dec 2021, наб via Libc-alpha wrote:
> If you'd hold on to your horses, like, until the next WG14 meeting,
I suspect we already have enough papers for the entire agenda of the next
(two-week) meeting (indeed, it seems plausible new feature consideration
will spill over to the July meeting and a C23 schedule delay will be
needed).
> turns out I know a guy who knows a guy, but my guy is the WG14 project
> editor, and I'm like, a day's away from getting an N number and turns
> out getting your "C defect" paper through is pretty easy if you don't
> have to sit in an NB meeting yourself.
I think this is more like a new feature than a defect (and one that
definitely needs to involve the Austin Group liaison, given that struct
timespec is a feature C got from POSIX, and maybe the C++ liaison - C++
liaison tends to work quite efficiently if you get papers on the agendas
for the liaison group meetings, but Austin Group liaison may be slower).
Note also that the next version of POSIX is aligning with C17, not C23.
On Tue, Dec 07, 2021 at 07:20:07PM +0100, Alejandro Colomar (man-pages) wrote:
> As Zack suggested, an unsigned version is probably unnecessary, so I'll use
> nsec_t for the patches, as you used in your draft. I like short names, and
> also signed types.
Great, this, if lands, will give glibc free compatibility with C2X.
> On 12/7/21 14:17, наб wrote:
> > You can find my current draft:
> > https://srhtcdn.githack.com/~nabijaczleweli/wg14/blob/868d3e096db0fe4378d77cd67215bed56045196d/N%3F%3F%3F%3F.pdf
> It looks good.
Thanks :0
> Would you mind sharing the source code of your pdf? I'm curious to learn to
> write those papers.
https://git.sr.ht/~nabijaczleweli/wg14/tree, but note that this is /far/
from a "good" or "normal" set-up ‒ most people use TeX,
and are proficient at it because they have a collegial education;
I started using groff -mom yesterday at 3am because I needed to make a
PDF and I'd remembered reading it was the strongest successor to -ms.
FTR: The PDF linked above was made at revision ee254af.
> Also, please CC me when you have any news on that :)
Will do.
> > accepting this would mean just a
> > typedef decltype(struct timespec::tv_nsec) nsec_t;
> > to make the implementation C2X conformant again.
> Hmm, not sure if it would be better for glibc to define nsec_t in terms of
> timespec, or the other way around. I had in mind something like the
> following:
I just meant that as an abstract short-hand form,
decomposing to roughly what you've out-lined below, yes.
Best,
наб
@@ -140,6 +140,14 @@ typedef __suseconds_t suseconds_t;
# endif
#endif
+#if defined __x86_64__ && defined __ILP32__
+typedef unsigned long long nseconds_t;
+typedef long long snseconds_t;
+#else
+typedef unsigned long nseconds_t;
+typedef long snseconds_t;
+#endif
+
#define __need_size_t
#include <stddef.h>