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

Re: svn commit: r11400 - trunk/subversion/libsvn_delta

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2004-10-14 19:46:46 CEST

C. Michael Pilato wrote:
> kfogel@tigris.org writes:
>>Resolve issue #2096: We were temporarily #defining MIN, and then
>>#undefining it when done. But some systems define MIN themselves, and
>>not only did our definition replace theirs (not a big deal, since ours
>>almost certainly did exactly the same thing as the system's), when we
>>later undefined it, we effectively removed both definitions. Oops.

Nothing wrong with removing a definition when we don't want to use it
within our .c file. (If this was a header file, then it would be wrong
to undefine it.)

>>Solution: use a different name.

Just another name from no particular name space? Ugh. In practice,
this is indeed less likely to clash, but no better in theory.

>>* subversion/libsvn_delta/compose_delta.c
>> (copy_source_ops): Use TMP_MIN instead of MIN, to avoid overlap with
>> a possible system-defined MIN.
> Er. I'd feel much better about one of the following two solutions
> over the one chosen:
> 1. Use conditional definition:
> #ifndef MIN
> #define MIN(a, b) ((a) < (b) ? (a) : (b))
> #endif
> And remove the #undef altogether.

That's reasonable.

> 2. Use SVN_MIN instead of TMP_MIN.

Putting it in our "own" name space at least helps us keep track of it
and makes it easier for other projects to avoid clashes with ours, even
though it does not guarantee it.

3. Just undefine MIN before re-defining it:

       #undef MIN
       #define MIN ...

    I'm pretty confident that a compiler is not allowed to complain
about undefining a symbol even if it was not already defined. And it
guarantees that we get the definition that we want.

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 14 19:44:18 2004

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.