Re: svn commit: rev 4739 - in trunk/subversion: svnadmin svnlook clients clients/cmdline tests/libsvn_subr svnserve svnversion

Branko Čibej <brane@xbc.nu> writes:
> The reason is very simple -- a) I'm lazy, and b) I don't have a Unix box
> handy to test on.
> There's really no obvious place to define that function in at the
> moment, and putting into a C file (and therefore compiling it
> separately) would mean I'd have to tweak build.conf, which don't want to
> do on Windows. I'd also have to tweak a load of .dsp's again, too.

Heh. Okay. I just thought there was some bizarre historical C
technique I'd never heard of, and I was trying to figure out the
reason, with no success.

> Correctness first, as usual. I'll fix these issues presently, but even
> deciding where to put such a function (it doesn't fit in any of our
> libraries) takes some thought.

Gotcha.

> Huh? Why would debugging into this function be any different from
> debugging into any other function? the debugger knows which source file
> the function is in.

It does? That's great. From the compiler's point of view it's N
different functions that happen to have the same name, where N is the
number of .c files that include this .h file (or so I would think).
It's the preprocessor that put the code there. I'm not sure how
debugging symbol tables are made, but I could imagine a universe in
which a debugger couldn't find the source for this...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 5 09:04:32 2003