>>
>> I'll edit it
>
> Thanks.
I've edited both the file, and the log message, and committed the changed
file, with an approriate log message (including a summary).
>> of habit. Especially since svn_boolean_type isn't a real boolean type,
>
> (I agree it isn't. You have to move to C'99 to get a real Boolean type in
> C.)
>> you'd want to know if it accidently took on some non-TRUE/non-FALSE
>
> Huh? Unless you write "if (b == TRUE) ...; else if (b == FALSE) ...; else
> error();" how would you know if it accidentally took on some
> non-TRUE/non-FALSE value?
Either that or
if (b == TRUE); else ... assert (b == FALSE);
Anything other than this or the formulation you wrote would silently
error.
I'll also note that you are more likely to catch semi-uninitialized (IE
along one path) use of a variable that the compiler doesn't notice if you
assert you are getting the values you expect.
In fact, that's the other reason it was written the way it was. The
compiler didn't notice that, along the way to fixing it, i had accidently
returned an uninitialized value into match along one path in
find_match.[1] The assert caught it though.
GCC's code, in most places, has a "real" boolean type accessible that the
compiler will bitch about if you mess around with in bad ways, so we don't
have to do this except in a small number of places. This only happened in
the past year or so though, and old habits die hard :).
Anyway, let me know if there is anything else you want me to remember to
do in the future that isn't in the HACKING file or obvious from most other
code. (or, add it to HACKING :P)
[1] I personally know the limitations of gcc and xlc's uninitialized
variable analysis. It's a war with users you can
never win. The better you are at detection, the more they expect you to
not miss other cases, even though you can't possibly detect every
"possibly uninitialized" variable without whole-program analysis.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 19 14:45:58 2005