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

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

We have N-th hand evidence that people noticed this. And I don't
particularly believe it; maybe someone didn't realize that you have to
include one of a couple specific header files to get size_t, or
concluded that it was defined incorrectly when it wasn't. That kind
of faulty conclusion is made all the time. On the other hand, a
missing or mis-defined size_t would almost certainly be noticed before
release on any system claiming to be ANSI C; all sorts of code uses
size_t, and has for a long time.

So that's just FUD, in my opinion, according to the information we
have in front of us now. I dislike seeing portability decisions made
based on FUD.

> The other thing is that this is not really extra cruft.

Sure it is. It may be a small amount of cruft, but anything which
goes into our source base and doesn't add any value is cruft, by
definition.

(Incidentally, I *can* respect Branko's argument that we should use
the apr type because it's our portability layer and That's The Way of
APR. No strong opinion either way on that argument.)
Received on Sat Oct 21 14:36:14 2006