Re: Programming language vote - results

[wtanksle@sdcc10.ucsd.edu (William Tanksley)]

In article <347C420A.2B18@sensor.com> Ron Natalie <ron@sensor.com> writes:
>William Tanksley wrote:

>> The malloc example *probably* has enough parentheses to force it to
>> work in the right order but the fact is that the code is obscure at
>> best and wrong at worst. It is also no more efficient when compiled
>> than the equivalent construct:

I did NOT write this.  I replied to this.  I disagree utterly with it.

>> It'll work, so long as the library returns zeroes for nulls.

>It works no matter what.  The constant zero is the null pointer
>constant.  If malloc returns a null pointer regardless of it's
>machine representation, testing it for equality against an
>integer zero (or the boolean not) will work.

I did write this.

NULL is defined as "(void*)0".  I've never seen a compiler which failed to
have (int)NULL be equal to 0 as well, but seeing one would not shock me --
according to K&R 2 (I don't have ANS C available right now) ANS doesn't
explicitly require that.

The worst part of that code, as far as I'm concerned, isn't the use of
pointers as booleans; after all, I can't imagine why a vendor would EVER
make non-zero NULL returns, especially since it would have to do a LOT of
work to make them meet the other requirements.  The bad part is that it
assumes that a pointer in an unknown state will be either NULL or
allocated.  Ick.  However, it could be that all the other code in the
application is a model of clear and precise code, so those are obviously
the only two possible states of the pointer at that point.  If so, that's
acceptable code.

-Billy