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: [RFC PATCH 00/52] Make GLIBC Y2038-proof


On Fri, Sep 8, 2017 at 1:24 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Fri, 8 Sep 2017, Zack Weinberg wrote:
>
>> Neither you, nor Rich, nor anyone else on the cited Austin Group
>> discussion has addressed the actual issue, which is that this is a
>> datum embedded in structures passed across the kernel/user boundary by
>> reference, it is impossible to enumerate all such structures,
>> therefore its type _must_ be a typedef so that it can be made to match
>> the kernel's expectations, whatever those might be.
>
> I don't see this as in any way an issue for having a definition of struct
> timespec that conforms to ISO C and POSIX requirements.  Code passing data
> to the kernel knows the structures being used locally and needs to convert
> it to the kernel's layout, which might be e.g. struct __kernel_timespec64.

This only works if all such structures can be enumerated and forced
through a compatibility layer.  History indicates that it is not, in
fact, possible to enumerate all such structures (the problem case I
know about is device-specific ioctl operations, which tend to be
created by driver authors who don't realize the need for ABI
compatibility shims until it's too late).

>> (And I don't particularly see why people seem to think this is an
>> x32-specific issue.  It potentially affects *any* 32-bit ABI on a
>> 64-bit kernel.)
>
> The kernel does the conversion just fine for a pure 32-bit struct timespec
> - as it does for the entire compat interface

For the reason given above, I confidently predict that there is at
least one failure to do this conversion correctly in every released
kernel ever.

>> <sys/types.h> doesn't exist in ISO C as far as I know, so how could it
>> be?  But any program that uses it opts into POSIX's specification for
>
> My point is that you can't expose nsec_t, even as a typedef for long, in
> <time.h> for C11.

I suppose it could be __nsec_t in time.h, but I would prefer to
include "and time.h defines nsec_t" in the scope of the willful
violation of C11.

zw


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