In message <[EMAIL PROTECTED]> on Tue, 4 Dec 2007 17:46:23 -0600, "Matthew D.
Fuller" <[EMAIL PROTECTED]> said:
fullermd> On Tue, Dec 04, 2007 at 07:58:02AM +0100 I heard the voice of
fullermd> Richard Levitte, and lo! it spake thus:
fullermd> >
fullermd> > I don't agree with that, as tally clearly has a boolean intent.
fullermd>
fullermd> Ah, but it doesn't; it's ++'d, not =1'd. Clearly it's a
fullermd> counter, not a boolean.
You do realise that we've left the realm of technological precision
and entered the realm of human subjectivity (something that C
obviously allows!) a long time ago, don't you? :-)
So you're zeroing in on the ++ and believe that says everything, eh?
However, considering how tally is used everywhere else, it's use is
boolean in the context that it is used. The way it's used, I can see
clear true/false semantics.
I suspect tally was used a bit more, but that the code has gone
through modifications since. This probably happened "before my time",
so to say...
fullermd> > "if (!tally)" could as well be "if (buf[0] == '\0')"
fullermd>
fullermd> But it could as well be "if (!buf[0])" too. Where do you
fullermd> draw the line?
You're absolutely correct, and again, we're in the realm of human
subjectivity.
fullermd> > That's misuse of a tristate value. It can't be used as a
fullermd> > boolean. This is a case where I agree with you.
fullermd>
fullermd> Well, but I see it (as well as the above) as the same case.
fullermd> It most certainly can be used as a 'boolean' in the C if()
fullermd> manner, since it returns something that can get treated as a
fullermd> number.
Ah, but since it doesn't return a number that has clear true/false
semantics, I can't see it as a boolean.
fullermd> And I've seen it so used more times than I have the stomach
fullermd> lining to recall. It's more amenable to such treatment than
fullermd> a pointer, come to that; it's only a tri-state, not a 2**32
fullermd> (or 2**64, for that matter)-state
No, the boolean semantics in C are clear: 0 is false, everything else
is true. It doesn't matter how many bits are involved.
fullermd> > fullermd> a fair number of C coding standards I've seen
fullermd> > fullermd> mandate no explicit comparison for obvious
fullermd> > fullermd> predicates, and require the comparison when it's
fullermd> > fullermd> not).
fullermd> >
fullermd> > Actually, I like that. Now, all we need to clear is what
fullermd> > constitutes the grey area of what is obvious and what is
fullermd> > not.
fullermd>
fullermd> Oh, well, that's the crux of the disagreement, isn't it? ;)
Isn't it always? I think it's called "being human" :-).
fullermd> I suspect that we've plowed this furrow pretty well by now,
fullermd> though. I think we're doomed to disagree. Worse, I think
fullermd> I'm outvoted :(. So, do you want to declare a Project
fullermd> Style on it, or leave it open?
Considering I view this as a community effort rather than My Project,
I view this discussion and the potential result the same way. So I
suggest that we keep talking but also start building a document that
can slowly evolve to something we all (or at least those who care) can
agree upon.
One way to resolve endless disputes is to actually leave the point of
discussion open or leave it as a recommendation. For example, what we
have discussed above could be summarised like this (I'm stealing your
examples):
--------------------------------------------------------------------
In all conditional/boolean expressions, it's recommended to have
explicit tests unless the expression is glaringly obviously intended
as a boolean. A few examples:
/* In this example, the function user_can_change() is obviously
intended to return a boolean value that it's unnecessary to
have an explicit test. */
if(user_can_change(this)==1) /* UNNECESSARY */
if(user_can_change(this)) /* GOOD */
/* In the following examples, the resulting values from
get_next_window() and strcmp() aren't clearly boolean, so
explicit tests of the results are recommended to avoid
confusion and programming errors. */
while((tmp = get_next_window())) /* CONFUSING */
while((tmp = get_next_window()) != NULL) /* GOOD */
if(!strcmp(x, y)) /* CONFUSING */
if(strcmp(x, y)!=0) /* GOOD */
In all cases when your code can be confusing, you're leaving
yourself open to possible critique and unnecessary questions.
--------------------------------------------------------------------
The rest is simply up to each. Considering I'm sure everyone has an
itch to scratch (like you most obviously do ;-)), whatever needs
changing will be changed.
Cheers,
Richard
-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
--
Richard Levitte [EMAIL PROTECTED]
http://richard.levitte.org/
"When I became a man I put away childish things, including
the fear of childishness and the desire to be very grown up."
-- C.S. Lewis
