[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnadmin hotcopy problem with strings > 2G

From: Ulrich Eckhardt <eckhardt_at_satorlaser.com>
Date: 2004-05-04 13:16:11 CEST

Dimitri Papadopoulos-Orfanos wrote:
> > The solution is rather to
> > #ifdef LARGE_FILE_SUPPORT
> > # define foo foo64
> > #endif
> > void foo(off_t);
> >
> > To make programs trying to load the wrong lib fail at (dynamic-)
> > linktime. One could even have support for both then, just as glibc has.
>
> I'm not sure what you mean by wrong library, or supporting both of them.
> Which wrong library? glibc has support for both of what? I think there's
> a misunderstanding about how large file support is implemented.

The question is, if "support for large files" is an optional feature or if it
is an alternative and how it is done.
- If, depending on this support, a library exports a symbol "foo" with
different interfaces, programs can fail silently when calling it. This is bad
and should be avoided.
- If, as glibc does it, it exports two versions of function "foo", one called
foo for the standard off_t and one called "foo64" for large file off_t,
things are fine.
- If, depending on the settings while building, it only exports either a
symbol "foo" or "foo64", then a program trying to link with one version but
expecting the other will fail, complaining that it can't find a required
symbol. This is still acceptable because it doesn't cause silent failures,
but if it is possible and the overhead is not too great, I'd rather always
export both versions of a function.

This is basically what is meant in [1], under the header "LFS and libraries
other than glibc".

Note: I just said that your advice was dangerous, not that it was wrong. It
really depends on the particular case and on the person knowing what they do.
To be honest, I don't even know how APR does it, so it could be that your
advice will not break things.

cheers

Uli

[1] http://www.suse.de/~aj/linux_lfs.html (thanks for the links, btw)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 4 13:16:55 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.