This is the mail archive of the 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: [PATCH] Y2038: provide kernel support indication

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 variable.

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?

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