subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fuhrmann <stefan.fuhrm...@wandisco.com>
Subject Re: svn commit: r1498169 - in /subversion/branches/fsfs-format7/subversion/libsvn_fs_x: fs_x.c hotcopy.c pack.c recovery.c revprops.c revprops.h
Date Tue, 02 Jul 2013 16:50:57 GMT
On Mon, Jul 1, 2013 at 2:01 PM, Daniel Shahaf <danielsh@elego.de> wrote:

> stefan2@apache.org wrote on Sun, Jun 30, 2013 at 18:46:54 -0000:
> > Author: stefan2
> > Date: Sun Jun 30 18:46:53 2013
> > New Revision: 1498169
> >
> > URL: http://svn.apache.org/r1498169
> > Log:
> > On the fsfs-format7 branch: fix a linker issue with the new fsx backend.
> > Give all non-static function a 'svn_fs_x__' prefix.  Update callers
> >
>
> I think that's a "workaround", not a "fix".
>
> The problem was that some functions were declared (and defined) in both
> libsvn_fs_x and libsvn_fs_fs, with the same name, same signature, and
> without a 'static' modifier in either case (since those functions were
> intended to be library-scope).
>
> Your change *avoids* the problem, but it doesn't *fix* it: if we have in
> the future another instance of identically-declared function in two FS
> backends, the situation where libsvn_fs_x calls into the libsvn_fs_fs
> version of the function may repeat.  (That'll hopefully result in
> a quick error or segfault.)
>

Well, the "bug" was that non-static function names should be
prefixed with the respective module name but these were not.
With "fixed" I meant: "now they are".

It seems to me looking into the linker options --- and seeing how
> libsvn_fs_x.so code managed to call into libsvn_fs_fs.so code --- would
> still be an interesting exercise.
>

Yes, that would probably be insightful.

-- Stefan^2.

Mime
View raw message