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

[Arnd Bergmann <arnd@arndb.de>]

On Monday 19 May 2014 14:46:59 Joseph S. Myers wrote:
> On Mon, 19 May 2014, Arnd Bergmann wrote:
>
> Now, when the motivation is not space reduction but ensuring nothing is 
> there that will break in 2038 (unless it's doing dubious things like 
> storing a time_t value in an int or long in the application - something a 
> reasonably stupid static analysis should be able to detect), you could 
> always identify the (symbol, version) pairs for a given architecture that 
> use 32-bit time_t and develop a tool that checks for binaries using 
> problem symbols.  (Of course, that won't help with ioctls.)  Or put a 
> small patch in the headers to force _TIME_BITS=64 and not allow an 
> override with _TIME_BITS=32.  And if the kernel had a config option to 
> disable all the old interfaces, that would make problem binaries break now 
> rather than in 2038.

I had already thought of the kernel option, that's probably one thing
we will do here, but it won't help if glibc then emulates the interfaces
we remove ;-)

A related question would be how you plan to support future CPU architectures
that never had the 32-bit time_t in the kernel ABI. Would you also want
to provide both 32 and 64 bit time_t to user space on those?

Then again I'm not sure how relevant glibc is to the deeply embedded
distros that would want to run without the backwards compatibility.
I suspect that uClibc, musl and bionic would just offer a compile time
switch without any emulation.

> > > > I don't know why timespec on x32 uses 'long tv_nsec', it does seem
> > > > problematic.
> > > 
> > > Yes, we have a glibc bug 
> > > <https://sourceware.org/bugzilla/show_bug.cgi?id=16437> about the glibc 
> > > definition (64-bit tv_nsec in x32 userspace to match the kernel's 64-bit 
> > > "long") being nonconforming, but without the kernel treating upper bits as 
> > > padding, fixing glibc requires wrappers that copy the value and clear the 
> > > upper bits.
> > 
> > Ok. There is also work going on to have an x32-like ABI for ARM64, and
> > that will likely have to support big-endian as well, so then it's not
> > just about clearing the padding bits, but also having them in the right
> > place.
> 
> Yes, I see no problem with putting the padding bits in the right place so 
> that when the kernel is passing struct timespec values *to* userspace, it 
> can just fill in the native 64-bit structure and have it automatically be 
> correct when interpreted as a 32-bit structure with padding (which the 
> kernel will have zeroed implicitly) on tv_nsec.

Ok.

	Arnd