Re: [PATCH 00/25] Change time_t and clock_t to 64 bit

["H. Peter Anvin" <hpa@zytor.com>]

On 05/18/2014 06:46 AM, Joseph S. Myers wrote:
> 
> It's advising against breaking compatibility with existing applications 
> (in that case, C90 applications that assume sizes can be cast to unsigned 
> long for printing, etc.) unless necessary.
> 

Yes, the values in question will not be a problem for that in this case,
so it doesn't apply.

> Rich Felker suggests 
> <https://sourceware.org/bugzilla/show_bug.cgi?id=16438> there are similar 
> security risks from various types in the x32 ABI being wider than size_t.  
> That seems entirely plausible, if unconfirmed; I don't think there's been 
> much effort to look for such issues where applications expect types to be 
> no wider than size_t when there's no use to them being wider than size_t.  
> Most of those choices are valid but may be risky to existing software much 
> as IL32LLP64 can be risky to existing software.

Everything can be risky if done poorly, unfortunately.

> The userspace ABI for struct timespec with 64-bit time_t and 32-bit long 
> should use long tv_nsec in any future ports, with appropriate conversion 
> code in glibc if the kernel interface is different (for ports that started 
> out with 32-bit time_t, conversion code will be needed anyway to convert 
> to the 32-bit structure if the new syscalls are unavailable at runtime and 
> so the old syscalls need to be used, but if the kernel's structure with 
> 64-bit time_t is different from that in userspace then both old and new 
> kernels need conversion code).  Given Rich Felker's bug reports, it seems 
> reasonable to suppose that musl will wish to do this as well as glibc.

This potentially requires the kernel to maintain three separate ABIs if
there is a legacy 32-bit ABI, which is quite frankly idiotic.  You seem
to be thinking of POSIX as something handed down by gods, which it
isn't... quite frankly they did something stupid here and should fix
their own mess.

As far as glibc is concerned, this would require glibc to intercept each
ioctl, which is completely infeasible... struct timespec/timeval is
embedded far too deep everywhere.

	-hpa