Bug#861026: both kernel and glibc want s64 not long (s32)
Control: reassign -1 glibc-doc-reference On 2017-04-24 08:15, Martin Pitt wrote: > Control: retitle -1 fix documentation of struct timespec' tv_nsec type > The glibc package doesn't provide the documentation as it is non-free. I am therefore reassigning the bug to the corresponding package. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Processed: Re: Bug#861026: both kernel and glibc want s64 not long (s32)
Processing control commands: > reassign -1 glibc-doc-reference Bug #861026 [libc6-dev] fix documentation of struct timespec' tv_nsec type Bug reassigned from package 'libc6-dev' to 'glibc-doc-reference'. No longer marked as found in versions glibc/2.24-10. Ignoring request to alter fixed versions of bug #861026 to the same values previously set -- 861026: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861026 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#861026: both kernel and glibc want s64 not long (s32)
Control: retitle -1 fix documentation of struct timespec' tv_nsec type Adam Borowski [2017-04-23 23:41 +0200]: > So no matter what we'd argue as being "correct", there's no changing the ABI > of an architecture that was finalized 5 years ago. Thus, all we can do is > having GNU folks document this. Yes, that's fine too. There's a similar ambiguity around time_t anyway. > On your side, I'd do an explicit cast to (int) and "%d" -- even on amd64 the > upper bits must always be 0 (or the kernel responds with -EINVAL). That's more or less what I did in https://github.com/cockpit-project/cockpit/pull/6374/files Thanks, Martin
Bug#861026: both kernel and glibc want s64 not long (s32)
> However, this is not. The documentation [2] defines struct timeval's "tv_nsec"
> field as "long int", so %ld is correct. But glibc seems to really define it
> as "__syscall_slong_t tv_nsec", and on x32 __syscall_slong_t appears to be
> "long long int".
> [2] https://www.gnu.org/software/libc/manual/html_node/Elapsed-Time.html
Both kernel and glibc use s64 in their ABI, and the high bits are actually
checked:
.--[ foo.c ]
#include
#include
#include
#include
int main()
{
struct timespec t;
t.tv_sec=1;
t.tv_nsec=0x1;
int ret = nanosleep(, 0);
printf("%d %s\n", ret, strerror(errno));
return 0;
}
`
amd64:
-1 Invalid argument
i386:
foo.c: In function ‘main’:
foo.c:10:15: warning: overflow in implicit constant conversion [-Woverflow]
t.tv_nsec=0x1;
^~~
0 Success
x32:
-1 Invalid argument
So no matter what we'd argue as being "correct", there's no changing the ABI
of an architecture that was finalized 5 years ago. Thus, all we can do is
having GNU folks document this.
On your side, I'd do an explicit cast to (int) and "%d" -- even on amd64 the
upper bits must always be 0 (or the kernel responds with -EINVAL).
It'd be interesting to see what's in arm64ilp32, though -- it's an
architecture that's in the same relation to armhf and arm64 as x32 is to
i386 and amd64, and it's about to get merged. Not in the merge window
that'll start in an hour-two from now, but possibly the next.
--
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!
