Re: HEADS UP: I will be merging christos-time_t by the end of the week

[christos%astron.com@localhost (Christos Zoulas)]

In article <20090105181558.GC708%britannica.bec.de@localhost>,
Joerg Sonnenberger  <joerg%britannica.bec.de@localhost> wrote:
>On Mon, Jan 05, 2009 at 02:57:00AM +0000, Christos Zoulas wrote:
>> In article <20090105025239.GD28903%britannica.bec.de@localhost>,
>> Joerg Sonnenberger  <joerg%britannica.bec.de@localhost> wrote:
>> >On Sun, Jan 04, 2009 at 09:13:57PM -0500, Christos Zoulas wrote:
>> >> - libc, provide compat, no bump
>> >
>> >What about structures that have inline time_t members? Otherwise
>> >this is a serious issue waiting to be hit. Just consider two different
>> >libraries, one old, one new, both using stat(2).
>> 
>> All have been versioned. Including rpc, etc.
>
>How can you version structures if libraries interact based on the
>expected format? If you have a library built with the old struct stat,
>it will fail if it gets a struct stat from a new libc and vice versa.

This has always been the case, and we have versioned struct stat
let's see, 4 times so far, and this will be the 5th. The short
answer is that if you recompile everything, things work. If you
don't compile anything new, things work. If you compile some libraries
selectively things should break. It seems that the reason that most
of the time things seem work with mixed old and new libraries is
that not many people pass struct stat between library calls.  I
think this will be much worse with christos-time_t because people
pass struct timeval and struct timespec much more frequently.

christos