Re: need advice on library interface
On Tue, Aug 06, 2002 at 12:43:17PM -0500, Joshua Haberman wrote:
> I don't see how this addresses the problem. I need a way to ensure a
> consistent ABI while supporting LFS and maintaining maximum portability
> (think HP-UX, Amiga, QNX, and vendor compilers).
If you need to make sure the ABI doesn't change, even when both 1: a
system gains LFS after an initial install of the library, and 2: the
library is reinstalled with LFS, I think you'd need to do the same thing
that _LARGEFILE64_SOURCE does: define normal and 64-bit versions of
functions, so the definitions don't change at all. That's a pain, of
course: it makes the library itself difficult to maintain and rather
inconvenient to use.
I suppose you could make the functions always take 64-bit integer types.
That is, roll your own off64_t type if one doesn't exist, and always take
that type even if you can't honor it. Then the ABI would only change if
it, for some reason, can't find a 64-bit integer type on one install and
can later.
> > Standard types that change based on configuration #defines are a pain;
> > if a library requires _FILE_OFFSET_BITS to match the setting in
> > applications, it'll cause problems if an application actually wants it
> > to be left alone for some reason.
>
> It is more than just a pain: it is a violation of the ABI. It also makes
> it impossible to mix libraries in some cases (like the
> libsndfile/wxWindows case that I mentioned).
That's why I'm suggesting (always) using _LARGEFILE64_SOURCE instead of
_FILE_OFFSET_BITS: it doesn't change any interfaces, it just makes
explicit 64-bit ones available.
--
Glenn Maynard
Reply to: