How should I test for a null pointer?

[Michael Foukarakis]

Actually, your being prone to these and other mistakes mean that you
had no standing in attacking Schildt or running your fat mouth about
other people's mistakes. Furthermore, the code you presented last week
(pseudo.c) shows that you never fix your own errors but expect others
to do this for you.

Nobody can fix their own errors. That's why we call them errors.

 

[Phil Carmody]

Nope:
"""
6.8.4 Selection statements
...
if ( expression ) statement
...
the first substatement is executed if
the expression compares unequal to 0.
"""

The expression that lies within the brackets is compared to zero.

I.e. the thing you give it is not necessarily a boolean expression,
a boolean may be only arrived at by subsequent comparison of your
expression to 0.

And even then, the comparison (assuming it's done via the "!="
operator) yields a result of type int. (An admittedly minor point.)

[...]

Not that minor, and I'm glad you made it, thank you. I was very
sloppy with my mapping of 'only the canonical false or true value'
onto 'boolean'.

Cheers,
Phil

 

[Nick Keighley]

Nobody can fix their own errors. That's why we call them errors.

well if someone points them out to you, you can. "Someone" can include
careful desk checking, testing, super-lint or some formal method.

 

[Julienne Walker]

On Mar 21, 3:08 am, (e-mail address removed) (Mark
Hobley) wrote:
How should I test for a null pointer within a C program?
Presumably the following will work:
[snip]
if ( !ptr ) { dosomething }
My follow-up question to the group is, how do you read the above line
of code in your head (or out loud)?
I find "if not non-null pointer" quite awkward.
FWIW: "if not ptr" where I usually vocalise "ptr" as "pointer".
Why not spell it out as I do consistently in my "convoluted" code
after my pre-Szymonyi Hungarian?

Why spell it out when the abbreviation is commonly known? In the case

See the discussion below. My international software and English
teaching experience has taught me not nought but aught, to be very
dubious about propositions to the effect that "everybody", even by gum
people in the next county, understands some abbreviation.

So what guideline do you apply to people who name variables in their
native language? I certainly have trouble understanding code where
variables are in Portuguese (which I don't know, obviously). I suspect
others are equally baffled by non-abbreviated words in a language they
don't know.

Abbreviations or not, commonly known or not, there's going to be
someone who doesn't know the word(s) you use. I'll defer to convention
rather than try catering to everyone in this case. It seems you do the
same, except with a different naming convention.

Julienne, I am not "fighting for fun".

It wasn't my intention to suggest you were. But you do strike me as
the kind who fights futile battles without realizing it.

http://xkcd.com/386/

<snip supremely stupid raving>

One reason I left the field was

.... clearly that you're paranoid, unsuited to professional
programming, and unable to acknowledge your own weaknesses. I can
easily see how you couldn't cut the mustard as a professional
programmer by reading your posts to this newsgroup. There's nothing
wrong with being unsuited to professional programming, of course, it's
not a threat to your manhood or your programming ability. Ours is
simply not the easiest field to work in. But rather than come to terms
with this, you believe yourself to be superior and blame everyone else
for pushing you out.

 

[Eric Sosman]

So what guideline do you apply to people who name variables in their
native language? I certainly have trouble understanding code where
variables are in Portuguese (which I don't know, obviously). I suspect
others are equally baffled by non-abbreviated words in a language they
don't know.

Off-topic (but on-thread) reminiscence: I once wrote assembly
code for a machine, using the abbreviation "SP" quite a lot -- and
it didn't mean "Stack Pointer." Anyone care to guess?

(Hint: The machine was a Siemens computer.)

 

[spinoza1111]

i, j, k is more normal.
Using l as a variable name, is a crime.

Yes, it looks too much like one. So is using o in lower or in upper
case.

L (lower case) appeared infamously in my edition of Numerical Recipes
in C.

 

[spinoza1111]

On Mar 21, 3:08 am, (e-mail address removed) (Mark
Hobley) wrote:
How should I test for a null pointer within a C program?
Presumably the following will work:
[snip]
if ( !ptr ) { dosomething }
My follow-up question to the group is, how do you read the above line
of code in your head (or out loud)?
I find "if not non-null pointer" quite awkward.
FWIW: "if not ptr" where I usually vocalise "ptr" as "pointer".
Why not spell it out as I do consistently in my "convoluted" code
after my pre-Szymonyi Hungarian?
Why spell it out when the abbreviation is commonly known? In the case

See the discussion below. My international software and English
teaching experience has taught me not nought but aught, to be very
dubious about propositions to the effect that "everybody", even by gum
people in the next county, understands some abbreviation.

So what guideline do you apply to people who name variables in their
native language? I certainly have trouble understanding code where
variables are in Portuguese (which I don't know, obviously). I suspect
others are equally baffled by non-abbreviated words in a language they
don't know.

World received English or Basic English (the language of world
aviation).

Abbreviations or not, commonly known or not, there's going to be
someone who doesn't know the word(s) you use. I'll defer to convention
rather than try catering to everyone in this case. It seems you do the
same, except with a different naming convention.

No, my international experience shows that World Received or Basic
English is measurably better.

However, a good programmer, in my view, sees good code even in another
language and set of conventions. For example, I could see that Willem
had written a great recursive replace() last month although he used
one letter abbreviations in a mathematical style.

It wasn't my intention to suggest you were. But you do strike me as
the kind who fights futile battles without realizing it.

(Sigh). These battles seem only futile in the corporation, but the
corporation is the problem as witness the corporate-funded battle
against health care (with the exception of pharmaceutical companies).

http://xkcd.com/386/


... clearly that you're paranoid, unsuited to professional
programming, and unable to acknowledge your own weaknesses. I can
easily see how you couldn't cut the mustard as a professional
programmer by reading your posts to this newsgroup. There's nothing
wrong with being unsuited to professional programming, of course, it's
not a threat to your manhood or your programming ability. Ours is
simply not the easiest field to work in. But rather than come to terms
with this, you believe yourself to be superior and blame everyone else
for pushing you out.

Julienne, I was in the field three times as long as the average
programming career which is ten years, and I left the field
voluntarily for a second career, as normal people often leave it, at
the age of 55.

This has given me in fact the independence to finally be clear on the
problem: that programmers need to engage in what Habermas calls
"critical reason" (this was obvious to Gerald Weinberg) while in the
corporation, reason itself is operationalized and quite subordinate to
the wealth of majority stockholders.

I started out long before most people here: my first program was
machine language, and after using assembler for a considerable amount
of new development that was needed at the time, I debugged a Fortran
compiler in machine language...etc., including the Nash true story,
etc.

But even then I was struck by the social impotence of programmers who
uniformly had to truckle like Dickensian clerks to management whim in
order to be employable, and who were constantly being deskilled.

I love it when a woman says "this is not about your manhood" because
she's engaging in negative logic. That's exactly what she means, and
she means to exert a quantum of social power that is negatively based
on her more globalized impotence as regards society, over men coded by
media as foolish and pathetic because they're not rich. As Lacan saw,
phallus worship has many guises.

I in fact celebrate the fact that I no longer have to work with, for,
or over pompous fools like Heathfield or fraudsters like Dweebach.
It's called freedom, dear.

 

[Dr Malcolm McLean]

On 3/23/2010 8:56 AM, Julienne Walker wrote:

Off-topic (but on-thread) reminiscence: I once wrote assembly
code for a machine, using the abbreviation "SP" quite a lot -- and
it didn't mean "Stack Pointer." Anyone care to guess?

(Hint: The machine was a Siemens computer.)

Something horrible.
I'd guess it was "stall processor" and you had to insert one of them
after every multiply and three after every divide, (unless the
preceding two instructions used logical operations only) or else the
instruction pipeline would lock and burn out the registers, resulting
in destruction of the machine.

 

[Seebs]

Nobody can fix their own errors. That's why we call them errors.

Actually, I frequently fix my own errors. Just not all of them.

As to pseudo, I've gotten probably under ten bug reports from
people other than me -- definitely under twenty, even if I grant all
four or five of the reports that Laszlo gave me. The vast majority
of bugs have been caught in my testing. The next largest category is
bugs I caught by inspection while browsing the code. (I'm not counting
bugs not-yet-found, because I don't know how many there are.)

The reason I talk about other peoples' mistakes is the same reason that
I hope other people will catch mine -- because humans are error-prone,
and the best way to reduce errors is to be consistently open to correction.

So, for instance, if people consistently point out mistakes I've made,
rather than trying to declare that the language is wrong and shouldn't be
like that, or calling them assholes, I generally just correct them and stop
making those mistakes as often.

-s

 

[Eric Sosman]

[...]
So, for instance, if people consistently point out mistakes I've made,
rather than trying to declare that the language is wrong and shouldn't be
like that, or calling them assholes, I generally just correct them and stop
making those mistakes as often.

It's said that the best response to a bug report is
"Thank you."

 

[Eric Sosman]

As I recall, a "null pointer" will compare equal to the integer constant
zero, but not necessarily to zero.

In other words, this will work:

if ( ptr == 0 )

but this may not:

int i = 0;
if ( ptr == i )

"May not," indeed. After issuing the required diagnostic for
violating the constraint of 6.5.9p2, the implementation is at
liberty to reject the code altogether. If instead it accepts and
runs the code, the effect of the forbidden comparison "may not"
be the same as the first form.

 

[Seebs]

[...]
So, for instance, if people consistently point out mistakes I've made,
rather than trying to declare that the language is wrong and shouldn't be
like that, or calling them assholes, I generally just correct them and stop
making those mistakes as often.

It's said that the best response to a bug report is
"Thank you."

Pretty much. Sometimes it's "Thank you, but that's the intended behavior"
or "Thank you, but your usage is incorrect", but in general, I try to err
on the side of fixing anything that looks like a bug.

-s

 

[Richard Bos]

! works well in some constructions:

"if(!done)", for example, reads as "if not done".

True, but you really shouldn't call a pointer "done" unless that really
is the only reason why you're getting that pointer. (E.g., if you're
calling a function which returns a pointer to data or null for
end-of-data, but you're only interested in its side effects.)

Richard

 

[Hamiral]

ptr = NULL; /* ptr has now been assigned */
if (ptr == NULL) ... /* ? */

You're nitpicking
Is it really necessary that I state that if a pointer is NULL I consider
it's "not assigned", even if it has been assigned a NULL value ?

ham

 

[Flash Gordon]

"May not," indeed. After issuing the required diagnostic for
violating the constraint of 6.5.9p2, the implementation is at
liberty to reject the code altogether. If instead it accepts and
runs the code, the effect of the forbidden comparison "may not"
be the same as the first form.

Further, and probably more to the point, if you cast i to an appropriate
pointer type (so no diagnostic is required) it still may not be
equivalent to the first form. The same applies, of course, it ptr is
cast to an appropriate integer type.

 

[Peter Nilsson]

How should I test for a null pointer within a C program?

if ( ptr == NULL ) { dosomething }
if ( !ptr ) { dosomething }

DEVENTER (n) A decision that's very hard to make because so
little depends on it, such as which way to walk around a park.
-- Douglas Adams & John Lloyd, The Meaning of Liff

 

[Eric Sosman]

You're nitpicking
Is it really necessary that I state that if a pointer is NULL I consider
it's "not assigned", even if it has been assigned a NULL value ?

It deprives you of the obvious way to describe the bug in

void func(void) {
char *ptr;
strcpy (ptr, "Goodbye, cruel world!");
...

 

[Keith Thompson]

You're nitpicking
Yes.

Is it really necessary that I state that if a pointer is NULL I
consider it's "not assigned", even if it has been assigned a NULL
value ?

My point is that you're using the word "assigned" with a meaning that
directly contradicts the usual meaning.

 

[Mark Hobley]

Of course, I never test booleans like if(somebool == TRUE)...

In other languages (where zero is true and non zero is false), I test booleans
in this manner.

if booleanvalue == TRUE

or:

if booleanvalue != TRUE

But in languages where zero is false, and non zero is true, then this form
is not suitable:

# FALSE and NOT FALSE is just nasty
if booleanvalue != FALSE # This looks really nasty. I wouldn't do that

In assembly language (on the 8086) we have:

jz label # jump if zero
jnz label # jump if non zero

(We can also easily use single bits to store booleans, which is rather nice.)

In C, I have implemented a kludge for boolean testing in the form of macros
istrue and isfalse:

if istrue(booleanvalue) {dosomething}

and

if isfalse(booleanvalue) {dosomething}

Mark.

 

[spinoza1111]

Actually, I frequently fix my own errors.  Just not all of them.

As to pseudo, I've gotten probably under ten bug reports from
people other than me -- definitely under twenty, even if I grant all
four or five of the reports that Laszlo gave me.    The vast majority

But ack and nak give error reports by falling through in a case
statement.

Please explain why this is so
I genuinely wish to know