[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: Dimitri Papadopoulos-Orfanos <papadopo_at_shfj.cea.fr>
Date: 2004-05-04 14:16:35 CEST


> 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.

This is never implemented like that.

> - 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.

That's how it's implemented on all Linux/Unix systems.

> - 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.

I'm not sure it's possible to tweak an existing library to export one
symbol or the other depend on the link options of a program that's using
it. But anyway, that not how it works.

> 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.

It's correct, and it's also not dangerous. The people who designed LFS
had of course thought about all these issues. Generally speaking, Unix
libraries don't evolve by breaking binary compatibility. If they do,
that's usually a bug. In the case of LFS, I've never heard of such a bug.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 4 14:17:41 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.