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

Re: CVS update: subversion/subversion/libsvn_subr hashdump.c

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-11-09 20:55:37 CET

Greg Hudson <ghudson@MIT.EDU> writes:
> It's cruft, it adds to the configure time, it could confuse someone
> later who doesn't understand why it's necessary, and there's no reason
> for it. (Really. size_t is almost universal even on pre-ANSI
> systems.) Make a couple score decisions like this and it can add up
> to a lot of cruft.
>
> This is a small issue, but I'm really confused as to why the sentiment
> is so different here than it has been on portability issues in the
> past.

Because some people reported encountering C environments that claimed
to be ANSI, but where `size_t' wasn't defined, or wasn't defined
correctly.

Yes, such systems are lying if they claim to be ANSI :-), but
autoconf's point is to deal with the real world. If Subversion can
otherwise build and run on such a system, then we should add this
macro.

The other thing is that this is not really extra cruft. Frankly, I
don't think it matters how many checks get added into the
configuration step, unless they're really expensive -- configure.in
consists of nothing but cruft anyway. I mean, it's not like code,
where all the parts interact and need to have their interfaces
maintained and all that ... Adding AC_TYPE_SIZE_T doesn't affect
anything else in the configuration process, and certainly doesn't
affect anything in the code, so it's not going to make anyone's life
harder in reality.

If this were a portability fix that would actual add to Subversion's
complexity, you'd see a lot more questioning about it, I think.
Received on Sat Oct 21 14:36:14 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.