From: Padraig Brady (padraig.brady at domain corvil.com)
Date: Tue 03 Sep 2002 - 09:35:57 IST
David Neary wrote:
> Nick Hilliard wrote:
>>>There's no requirement to use an integer type for time_t at all.
>>Except for backwards compatibility. Changing the size would break
>>compatibility with nfs, most filesystems, everything in <time.h>, rpc
>>and a large number of the ABIs and libraries in existence.
> Backwards ABI compatibility is a convenience, rather than a
> requirement. The time.h declared functions would of course be
> implemented with the new time_t (they'd have to be) - I don't see
> how it would break nfs.
> The bottom line is that pretty much all code which assumes that
> time_t is an integer type is broken. All code that assumes time_t
> is a 32 bit integer type is very broken. Once the underlying
> time_t changes in the implementation (in this case, glibc), all
> code should be pretty much able to handle the new one with a
> recompile. Any code that can't is (you've guessed it) broken.
Just another data point to this.
With glibc versioning is done like: major.minor.subminor
major breaks the API (possible code rewrite)
minor breaks the ABI (recompile required)
subminor breaks nothing.
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:18:36 GMT