Re: libelf

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> To really fix it, FILE would have to become truly opaque, without
>> accessors/mutators except for stdio-exported interfaces.
> That wouldn't fix it either, unless you never tried to make a change
> to FILE and provide backwards ABI compatibility.

It's difficult to need backwards ABI compatability when (a) stdio is
the only ultimate producer or consumer of FILE *s (ie, producer or
consumer who doesn't just produce them from elsewhere or consume them
only to pass them along) and (b) stdio's API is stable.

> [...]
>   struct thing *thing_create(void);
>   void thing_frob(struct thing *, int code);
>   void thing_destroy(struct thing *);
> [...]
> Now suppose the maintainers of libfoo extend the functionality so
> each thing needs to hold more state.  In order to do this in a
> compatible way, they create the following internal types:

They don't need to do anything of the sort, because the only way
applications can get a thing is to thing_create() it.  There is no
issue unless (a) the old struct thing * and the new struct thing * are
argument-passing-incompatible, (b) some call is being removed, or (c)
some existing call is being changed in an ABI-incompatible way (eg,
growing an extra argument) - and I'm not sure (a) can happen, given C's
rules about compatability between incomplete struct types and their
completed versions.  Merely changing struct thing from "int state" to
"long state" - or even "long state[64]" - doesn't cause any of these.

In the case that got us here, libcurses and FILE *, provided libcurses
sticks to stdio-exported interfaces - provided it never goes under the
hood of a FILE - there is no issue, even if stdio changes, unless (a)
the changes make FILE * change passing-convention-incompatibly, (b)
some stdio interface curses uses is being removed, or (c) some stdio
interface curses uses changes incompatibly.  None of these are
plausible, and merely changing the internals of the struct known as
FILE causes none of them.  (Changing the struct tag could, but I doubt
there are implementations where it would, possibly excepting some that
go out of their way to break assumptions the language does not promise
but which are nigh-universally true anyway.  Changing FILE from a
struct to a primitive type, or the converse, could, but I don't think
that's what was being discussed.)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B