Steve Langasek wrote... > I don't have any inkling how widespread this problem will be nor do I see > any path towards automatically detecting such issues (a codesearch on time_t > would return far too many false-positives to be useful).
While I doubt there is a perfect way to auto-detect this, I see some
things that could be tried in order to make the haystack smaller.
My first idea was to check for "Using 32bit time_t in a packed
structure", something a C compiler could warn about - assuming
on-disk/wire format data is handled in C structs, and omitting the
"packed" attribute should have created trouble years ago.
That would not help though if programmers just use an 32bit integer
to store time information. and I guess they did. Idea: Re-use some code
analyzer to look for 32bit integers that have "time" in the name. To
support this, a rough codesearch for "[iu]32..*time[^o]" instantly gave
me some moments of "Oh, not looking good", although also several
false-positives.
And, assuming there is a sane testing available (autopkgtest would be
really handy), run it with a mocked system time.
Set the time to some point pre-2038, hook the write operations, inspect
all data for four-octect sequences that resemble the time (with some
offset) but lack adjacent four octets of value zero that would make it a
64bit time. Repeat for various times and for both endianesses to improve
precision.
And of course, set it post-2038 and see what happens. Brace for impact.
Christoph
signature.asc
Description: PGP signature
