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] |
On 7/29/19 4:08 PM, Joseph Myers wrote:
What it would require is to add compat implementations with a different type, time32_t for instance. Something like:That seems much harder to implement through incremental development, whereas with _TIME_BITS=64 things can readily be implemented incrementally
I worry that this puts the incremental cart before the incremental horse, at least for portable applications. If we take the _TIME_BITS=64 approach, portable applications should add the equivalent of "#define _TIME_BITS 64" to their config.h files or ihatever, because they should be Y2038-safe. But if glibc development is incremental so that some time_t uses are glitchy when _TIME_BITS=64, these applications will have problems. Conversely, if glibc doesn't publicize the time_t changes until they're ready (which I think is the intent), the _TIME_BITS=32 approach would be less hassle overall for portable applications; they won't have to change their source code.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |