jdp at polstra.com
Thu Feb 26 12:20:35 PST 2004
On 25-Feb-2004 Garance A Drosihn wrote:
> At 4:45 PM -0800 2/24/04, John Polstra wrote:
>>Well, Modula-3 still thinks time_t is 32 bits, of course. I haven't
>>looked at the patches for a 64-bit time_t, so I'm not sure what
>>provisions have been made for backward compatibility.
> None. We change the type for __time_t, and recompile everything.
> This puts us in the same camp as the amd64 and ia64 ports. We
> pretend that the sparc platform never had a 32-bit time_t.
>>I assume you (the collective "you") kept compatibility versions
>>of time(2), stat(2), lstat(2), etc., with 32-bit time_t fields
>>so that existing executables would continue to work.
Ugh. Do you folks fully realize the implications of that? Consider
the numerous as-yet unidentified pieces of code out there that look
/* ... */
/* ... */
All of a sudden, without any warning, the time() call is likely to
start scribbling a 0 into either "a" or "b" -- or, worse yet, into
half of the return address or frame pointer. Who knows what the
symptoms of that will be? Will they be deterministic? Will they
cause ugly security vulnerabilities? Whee!
I don't have a SPARC machine, so it's no skin off my nose. But I
think you folks might come to regret it if you take this shortcut.
This platform has already been around for a year, and people have
developed certain expectations. You can't just say, "We warned you,"
and expect that to make everything all right. You're likely to end
up with a whole bunch of unhappy users with broken machines and no
workable path forward or backward. Have fun dealing with that! :-)
I've been around here since 1995, and I've seen people talk
themselves into skipping the backward-compatibility step before.
They practically always regretted it. I think this is likely to be
one of those cases.
More information about the freebsd-sparc64