This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Y2038: provide kernel support indication
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: "Albert ARIBAUD (3ADEV)" <albert dot aribaud at 3adev dot fr>, libc-alpha at sourceware dot org
- Date: Wed, 19 Sep 2018 09:11:18 -0700
- Subject: Re: [PATCH] Y2038: provide kernel support indication
- References: <email@example.com>
Albert ARIBAUD (3ADEV) wrote:
+/* Indicates Y2038 support.
+ * 0 means no suppport
+ * > 0 means (some) support
+ * < 0 means support is broken
+ * Can be read directly from within libc linux-related files.
+ * Can be written non-zero to indicate support or lack thereof.
+extern int __y2038_linux_support;
This variable needs a better comment, since it's not clear from that comment
what it's for. In the current branch, I don't see any code setting the variable
to a positive value; it defaults to 0 and if any glibc code discovers anything
that looks like a y2038 bug, the variable is set to -1.
So it looks like a cache: as glibc discovers y2038 bugs, it uses the cache to
avoid trying to invoke system calls that it knows will fail anyway with ENOSYS,
or something like that. If that's the intent, it needs to be documented in the
However, I imagine that some kernels will have some y2038 bugs but not others.
For example, clock_gettime and related functions might work fine on a particular
kernel, but some ioctls might not work (or might work for some devices but not
others) due to device-drivers not being y2038-safe. How is __y2038_linux_support
supposed to reflect this more-complicated situation?