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

Re: Any idea why public function like "svn_fspath__dirname" have double "__" in its name?

From: Branko Čibej <brane_at_xbc.nu>
Date: Wed, 29 Dec 2010 11:19:34 +0100

On 29.12.2010 09:43, Branko Čibej wrote:
> On 28.12.2010 23:13, Peter Samuelson wrote:
>> [C. Michael Pilato]
>>>> svn_fspath__is_canonical
>>>> svn_fspath__dirname
>>>> svn_fspath__basename
>>>> svn_fspath__split
>>>> svn_fspath__join
>>>> svn_fspath__is_child
>>>> svn_fspath__skip_ancestor
>>>> svn_fspath__is_ancestor
>>>> svn_fspath__get_longest_ancestor
>>>> svn_error__locate
>>>> svn_error__malfunction
>>> While we've mandated that "__" must be used for semi-public
>>> functions, we've never said that it can't be used for private ones.
>> Kamesh is talking about public, not private, functions. I.e., ones
>> where we actually do have an ABI promise to keep.
>> I looked at svn_error__locate last week. It's really only useful in
>> --enable-maintainer-mode, but the way it's implemented, it ends up
>> being used by macros in the public (non-maintainer) ABI, so even if we
>> eliminate those callers, we have to supply the function itself forever.
>> I've addressed this as best we can, in r1053469.
> Now I'm really mystified. When I added those location-tracing functions
> and macros, they were only ever enabled with SVN_DEBUG turned on (i.e.,
> in maintainer-mode). Now I see that those #ifdef wrappers are gone, and
> can't recall an explanation as to why that's a good thing.
> Can anyone remember what that change was good for?

Found it, r843793 and I agree with the change. So, effectively,
svn_error__locate has been public since then, and r1053469 should be
reverted anyway because it breaks the ABI.

The name may or may not be misleading, depending on interpretation ...
no-one should call svn_error__locate directly, the public API are
effectively the macro wrappers.

-- Brane
Received on 2010-12-29 11:20:16 CET

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

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