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

[Guido Draheim]

Paul Eggert schrieb:
> > Date: Sat, 11 Jan 2003 18:45:30 +0100
> > From: Guido Draheim <address@hidden>
>
> > The problem only exists when off_t creeps into public headers usable
> > by third party applications,
>
>
> Not true.  The problem can exist even if the public headers export
> only 'int'.  For example, libraries can export large-file-aware file
> descriptors into non-large-file-aware applications.  And it can also
> exist even if the public headers export only 'long'; ftell is an
> example of this problem.

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, that might result from
some operations done in the non-large-file-aware application.

As for ftell, again, it _must_ result in an EOVERFLOW if the
result does not fit - it does make for a callframe mismatch
or structsize mismatch resulting from differently sized
off_t types in the sharedlib and application code.

> The problem of supporting mixed-mode applications is much more
> complicated than what you seem to be suggesting.  We should not
> suggest to developers that they take that path.  It is a long, hard,
> and bug-prone road, and there's little payoff at the end.
>
> 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 - because the original author
can not quite decide how plugin modules get compiled...
$ objdump -T /usr/lib/kde3/*.so | grep " f*open"
in here, it is not that simple anymore - it is dependent on
humans an their skills and varying intents. The best way is
still to find a technical means which is not easy either.

> > +checking for off_t... yes (largefile sensitive)
> >
> > A developer will surely see it and try to get the answer as to
> > what that actually means
>
>
> I'm skeptical.  Most people don't read or understand those messages,
> unless perhaps the compilation fails.

if they ignore it, fine, but they've been warned - and when there
is a problem, people will check that one more closely :-)=)

> How about if we change AC_TYPE_OFF_T to invoke AC_SYS_LARGEFILE by
> default?  If you want a small-file program, you'd have to invoke
> AC_CHECK_TYPE(off_t, long) instead.  That might help a bit.

It's a change in behaviour. Perhaps introduce AC_TYPE_OFF64_T
instead that #defines to off_t if the current system is neither
largefile-sensitive and has off_t available. The AC_SYS_LARGEFILE
is not used that often, just probably because people don't ever
noticed the problemspace of non-fixed-size off_t - with some
sister macro AC_TYPE_OFF64_T being found next to AC_TYPE_OFF_T,
well that might change things. Slightly.

> But I'm becoming more inclined to think that we should invoke
> AC_SYS_LARGEFILE by default, unless the user explicitly says he 
> wants 32-bit off_t.
>

Hmmm, depracate ac_type_off_t and make up two new macros? See,
I don't like behaviour changes in the middle of life, it's a
pain for people who are about to upgrade their software tools
and have (silent!) changes in the behaviour of their software.

Atleast, I'm with you in the preference of using 64bit off_t
as soon as it is available, and somehow guide the developer
to go with it.

Anyway, what do other autoconf people think about this
matter? It seems we two have just differing views on how
easy it is to force people into the 64bit off_t world.

-- cheers, guido