Re: ac-archive: ac_sys_largefile and libraries...

[Guido Draheim]

Paul Eggert schrieb:
> > Date: Sat, 11 Jan 2003 19:30:54 +0100
> > From: Guido Draheim <address@hidden>
>
>
> > > The problem can exist even if the public headers export only
> > > 'int'.
>
> > I don't see the point - the largefile specification describes
> > that libc calls must check whether the filedescriptor has been
> > opened as an O_LARGEFILE one, and act accordingly. The only
> > thing is a new error-code, EOVERFLOW
>
>
> The point is that older applications may not know about EOVERFLOW, or
> may assume that a failure means that a file is not accessible, or
> whatever.  The mismatch will break the program.  I've seen it happen.
>
>
> > As for ftell, again, it _must_ result in an EOVERFLOW if the
> > result does not fit
>
>
> And old programs (reasonably) assume that ftell cannot fail under
> ordinary circumstances, and break when it does fail.  The breakage
> is just as real as callframe mismatch.

hmmm.

A.1.1.4 Holes in the Protection Mechanism

The following holes in the protection mechanism are discussed in other
sections of this document:

   * While a "small" application has a file open another "large" application
     can extend the file (see A.1.2.1 Offset Maximum).
   * The fcntl() function may inadvertently clear O_LARGEFILE (see A.3.1.1.1
     fcntl()).
   * The lseek() failure may result in corruption of log file or database
     (see A.2.1.1.6 fgetpos(), fseek(), ftell(), lseek()).
   * An open file description with a "large" offset maximum may be inherited
     by a "small" application (see A.1.2.2 Inheritance).

A.2.1.1.6 fgetpos(), fseek(), ftell(), lseek()

These functions will fail if the resulting file offset would exceed the
largest value that can be represented correctly in the related type which is
in use for the call, and will set errno to EOVERFLOW (permitted by PASC
Interpretation 1003.1-90 #75).

Programs typically, but incorrectly, fail to check the return value of these
functions, which renders the error return less useful. On the other hand,
returning an incorrect offset can result in serious malfunction as well.

>>Perhaps introduce AC_TYPE_OFF64_T
>
>
> That is not a good name, because that should define off64_t, and the
> whole point is to avoid the use of off64_t entirely.
>
Yes that was the point - it *should* declare off64_t, even on systems
that have only 32bit off_t and where there is no largefile support at
all. Those are pre-unix98 actually, since unix98-compatible systems
are required to have largefile support.


> > > We should instead tell people the much simpler solution: don't mix
> > > object modules compiled in different modes.  This is easy to
> > > understand, and it works.
> >
> > That's an administrative task
>
>
> Yes, and it's a much easier administrative task than to tell
> application and library authors about mixed-mode programs.  Mixed-mode
> programs are a mistake, regardless of whether you consider them to be
> an administrative task or a technical task.  For free software,
> mixed-mode is way too-much work for way too-little benefit.
>
> For closed software, mixed-mode makes more technical sense in some
> cases; but Autoconf maintainers shouldn't waste their time supporting
> features that are useful only for closed software.

I am coming to the conclusion to approach distro makers - the rpm
packaging script do currently chrpath the .so libraries atleast
(as they are usually installed in a DESTDIR staging area, and
libtool does relink them up there) - so, why not let those scripts
check for spurious instances of fopen/lseek and friends and warn
at them - so that libraries and modules are compiled 64bit always
(using the alternate symbols fopen64/lseek64 instead, ye know).

Perhaps... even let them check any other ELF binary around and
suggested to be packaged into an rpm (or any other packaging format).
That might get us rid of the problem altogether and with the help of
technical tools that will bark at anything not compiled 64bit-off_t.
That would have also detected the zlib to be 32bit-off_t and this
whole thread probably to have never existed since the problem would
only exist in theory (for software compiled from sources and get
into the bin areas) as any software of some importance would have
been checked at some point of getting compiled as largefile by
default - simply for the correlation that any mildly important
software gets to be distributed in a binary package at some point.

what about that one?