On Wednesday, June 29, 2016 1:16:11 PM CEST Albert ARIBAUD wrote:
On Wed, 22 Jun 2016 13:55:16 +0200, Arnd Bergmann arnd@arndb.de wrote :
On your note "The implementation needs further thinking about, as application code defining _TIME_BITS=64 and gets built against new kernel headers and old GLIBC headers, then GLIBC will use 32-bit time_t and kernel will expect 64-bit time_t, and there is no way to ensure detection of this case.", I think that is covered by having the kernel headers check __USE_TIME_BITS64 instead of _TIME_BITS=64, as I described above.
What about application source code which includes kernel headers before including any GLIBC header? The kernel header will see __TIME_BITS=64 but it won't see _USE_TIME_BITS64, and will make the wrong decision. Don't we consider this a possible scenario?
Good point, I think you are right that this is a problem. In particular, the normal rule for kernel headers is that they should explictly not include any libc headers or rely on them to be included first. We have some exceptions from those rules for historic reasons.
Do you have any other ideas for how to solve it? We probably only need a handful of those, so we could look at them case-by-case to see what kind of exception we can make.
Arnd