This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Add LOAD_ARG[1-6]_TYPE and x32 posix_fallocate.c


> For int32_t, it makes no difference between unsigned long long int
> and long long int for both x32 and x86-64 since kernel access it
> as int32_t.

OK.

> The only problem is off_t, which is int64_t for both
> x32 and x86-64.  Again, it makes no difference between
> unsigned long long int and long long int for both x32 and x86-64.
> There are no other system calls in C which has int64_t for
> arguments.

So then using 'unsigned long long int' in the syscall macros would be fine.

> For those system calls which take uint64_t, long is fine for x32 since
> casting from unsigned long to long will zero-extend to uint64.

This doesn't make any sense.  uint64_t is 'unsigned long long int'.
Casting it to 'long int' will truncate to 32 bits.

> So using  'unsigned long long int' isn't necessary for neither
> x32 nor x86-64.

As it stands today, the syscall macros use 'long int'; on x32, this
truncates to 32 bits, which breaks all 64-bit arguments.  (If that weren't
the case, you never would have proposed the kludge for posix_fallocate.)
If we changed it to 'long long int' then pointer arguments would get
sign-extended, which would break everything.  So 'unsigned long long int'
is the option that makes no difference to x86_64, makes x32 pointer
arguments work, and makes x32 int64_t arguments work.  Am I confused?


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]