begin quoting Andrew Lentvorski as of Sun, Nov 18, 2007 at 09:46:45PM -0800: > Stewart Stremler wrote: > >begin quoting Gregory K. Ruiz-Ade as of Sun, Nov 18, 2007 at 01:48:31PM > >-0800: > >[snip] > >>one would hope that most programmers were intelligent and used time_t, > >>rather than making assumptions. such hope, unfortunately, might be > >>futile. > > > >The problem is that time_t is a hack. And an ugly one at that. > > That's not the real problem. The problem is that time_t gets mapped to > a specific size by the *compiler* rather than the *linker*.
Well, that's what happens when you have structures, compilers, and data segments. The linker doesn't have enough information, and if it did, it would be compiling, not linking, and so not really a linker anymore. This may not be a bad thing. > Consequently, 2 libraries can be compiled perfectly correctly and > *still* fail to interoperate because one library thinks time_t is > 32-bits and the other thinks time_t is 64 bits. ...which is my point: time_t is a hack. It's using the preprocessor instead of a language-defined type or OS-defined opaque structure. The thing is, it's "good enough". It's not going to be a problem for nearly thirty years for most programmers. By then, the 32-bit machines will be mostly gone. > I believe that this is the kind of thing that LLVM was supposed to > alleviate: > http://llvm.org/ Hm. Interesting. But I'm not entirely sure it would work. LLVM's intermediate format specifies the sizes of the data used; you'd get a link failure, not interoperability, I think (from skimming some of the LLVM documents). Which is *probably* good enough, else you'd allow for silent truncation (pass a 64-bit value through a 32-bit library and back out) which counts as a bug most of the time. -- Why invest in forward compatiblity when you can sell more product if you don't? Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
