Hal Murray <hmur...@megapathdsl.net>:
> I think the main issue is code simplification and clarity.
>
> Plan A: get rid of time64_t
> Plan B: convert all internal use of time_t to time64_t
>
> If the world is going to shift to a 64 bit time_t soon enough, then Plan A
> make sense. We get clean code and it will just keep working when 2038
> happens.
>
> We will have to figure out how to handle %ld vs %d in printf format strings.
>
> Plan B would require conversions between time_t and time64_t at all
> system/library calls. That's probably just a simple wrapper for the calls
> used often enough and a dummy variable and few lines of code for the others.
I think we can hang with Plan A for now. That judgment might have to change
in 10 years if we see any significant number of 32-bit systems in our target
range, but *by then* I'm not expecting that.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
