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

Re: svn commit: r18486 - trunk/subversion/libsvn_ra_serf

From: Daniel Rall <dlr_at_collab.net>
Date: 2006-02-20 07:03:55 CET

On Fri, 17 Feb 2006, Julian Foad wrote:

> Greg Stein wrote:
> >On Fri, Feb 17, 2006 at 01:21:47PM +0000, Julian Foad wrote:
> >
> >>Justin Erenkrantz wrote:
> >>
> >>>Therefore, each variation would ultimately need its own #define and
> >>>keeping track of that - since a #define would be separated from the
> >>>actual loop into a header file (meaning every time I tweak it,
> >>>everything in the library needs to be recompiled) - is what I feel
> >>>isn't right at this early stage. -- justin
> >>
> >>FWIW, a #define doesn't have to be in a header file just because it's a
> >>#define, only if it is intended to be shared. If it's only for local use
> >>in one C file it belongs in that file.
> >
> >If it is used in one place, and the intended use for the value is
> >obvious (as it is in this case), then a symbol doesn't help much.
> >
> >IMO, find another thing to nitpick that has more benefit :-)
>
> Yep, I should have restrained myself from sending that email. Sorry folks.

Well, the issue was that the magic value (8000?) was used in a couple
places, which was normally warrant a #define in the source file or a
module-private header file. However, Justin went on to explain that
even though the values were currently the same, that they likely
wouldn't remain so (after profiling or something?); more importantly,
sounded like each usage actually had fairly different semantics, even
though the same magic number was being passed to the same function.
It's understandable that a couple of us noticed it and commented.
*shrug*

-- 
Daniel Rall

  • application/pgp-signature attachment: stored
Received on Mon Feb 20 06:34:20 2006

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.