How should I test for a null pointer?

[Mark Hobley]

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

Presumably the following will work:

if ( ptr == NULL ) { dosomething }

I have also seen the following, but I am unsure on this because can the value
of a null pointer be guaranteed to be zero? If it is not zero, does the pling
operator recognize this anyway, and the condition still works?

if ( !ptr ) { dosomething }

Or should I be using something else to test for a null pointer?

I am using C89, if that matters.

Mark.

 

[Seebs]

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

if (!ptr)

in my opinion.

I have also seen the following, but I am unsure on this because can the value
of a null pointer be guaranteed to be zero? If it is not zero, does the pling
operator recognize this anyway, and the condition still works?

if ( !ptr ) { dosomething }

!ptr is the same as (ptr != 0), and the 0 would be converted to a null
pointer.

In short, no matter what pattern of bits in memory represents a "null
pointer", it compares equal to zero, and is thus "false".

-s

 

[Dr Malcolm McLean]

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

Presumably the following will work:

if ( ptr == NULL ) { dosomething }

I have also seen the following, but I am unsure on this
if ( !ptr ) { dosomething }

Either is fine and you will see both. If NULL is not all bits zero the
compiler has a special patch to make it arficially equal to zero for
the purposes of C expressions.

The main issue is that NULL is ALLCAPS which gives it an emphasis it
really shouldn't have, whilst ! may be lost visually. == 0 doesn't
make it clear that the variable is a pointer whilst == (void *) 0 is
wordy. So there's no absolutely ideal syntax.

 

[spinoza1111]

        if (!ptr)

in my opinion.


!ptr is the same as (ptr != 0), and the 0 would be converted to a null
pointer.

In short, no matter what pattern of bits in memory represents a "null
pointer", it compares equal to zero, and is thus "false".

-s

Which makes C rather hard to use in any embedded environment where the
program needs to use location zero. But I thought C was great for this
type of environment. But hey, I'm The Greatest Programmer in the
World, but I know dick about C.

Seriously, modern platforms do not allow the programmer to make puns
about null versus zero, for a very good reason. Rather like the use of
Nul, it is a barbarism which assigns special juju to zero in a holy
dread, whereas mathematicians since the Arabs have known that while
zero has special properties it is just another number.

The fact is that the Multics and Algol teams were trying, in Habermas'
sense, to engage in critical reason at a time when operational (profit
and rent seeking) reason was rapidly colonizing the lifeworld. Rather
than being fighters for the Revolution, Pike, Ritchie, and Kernighan
unwittingly served the ends of corporations by reifying stupidity in a
way that's propagated and made infants out of real programmers.

Yes, nullity is zero, and this is another bug in C.

 

[spinoza1111]

On 21 Mar, 08:08, (e-mail address removed) (Mark Hobley)
wrote:> How should I test for a null pointer within a C program?




Either is fine and you will see both. If NULL is not all bits zero the
compiler has a special patch to make it arficially equal to zero for
the purposes of C expressions.

The main issue is that NULL is ALLCAPS which gives it an emphasis it
really shouldn't have, whilst ! may be lost visually. == 0 doesn't
make it clear that the variable is a pointer whilst == (void *) 0 is
wordy. So there's no absolutely ideal syntax.

Which is why we should have fun with it, in my opinion. While not
sacrificing readability, we should make fun of pompous C gnomes:

#define TRUTHINESS -1
#define FALSINESS 0
#define NULLOSITY 0

One mark of the individually (or here collectively) barking mad: lack
of a sense of humor: when physicist Freeman Dyson noted the return of
John Nash's dry sense of humor in the late 1980s, he took this as a
sign of recovery.

Indeed, "programming coding standards" should never be imposed, either
by managers OR by fat, substance abusing creeps who think they're
experienced programmers.

Everyone should be allowed to use their own style. If someone wishes
to write a poem in honor of his programming in a lead comment, he
should not be fired: he should be crowned with laurel leaves and sent
out for pizza.

But: everyone should be as competent as me or Willem or Malcolm, to
name three of the people here who are in my opinion competent without
having the stunted personality that often accompanies developing
competence in programming while adapting to horrors like C.

But if they are, they should make jokes at the expense of software and
hardware.

As it is, everyone here is involved in a growing form of real
Satanism: the replacement of decency and respect for the only
incarnations of that which is worthy of decency and respect (people
and nature) by the worship of absurdity and things. You insult Schildt
without once taking into account the effect on his family of making a
joke of his name, and laugh at him: but let anyone laugh at C and you
get grave and serious and call security.

**** that shit.

 

[Ben Bacarisse]

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

Presumably the following will work:

if ( ptr == NULL ) { dosomething }

Yes, that's fine.

I have also seen the following, but I am unsure on this because can the value
of a null pointer be guaranteed to be zero? If it is not zero, does the pling
operator recognize this anyway, and the condition still works?

if ( !ptr ) { dosomething }

That's also fine.

Formally, !E is defined to mean E == 0. Comparing a pointer with the
constant 0 just tests whether that pointer is or is not null. It is
unaffected by how a null pointer is represented internally.

Even in the oddest of implementations where there might be multiple
representations for null pointers (with none of them being all bits
zero) the comparison must work.

Finally, if you swap the test over and write:

if (ptr) { /* do another thing */ }

then you rely solely on the meaning of the 'if' test. In C, the
statement controlled by the 'if' is executed when the controlling
expression compares unequal to zero. I.e., once again we rely on the
meaning of E == 0 and E != 0.

[You'll notice that this means that 'if (!ptr)' actually relies on the
meaning of (ptr == 0) != 0, but since == gives either 0 or 1 there is
nothing interesting to learn from adding in that last step in the
reasoning.]

 

[Barry Schwarz]

if (!ptr)

in my opinion.



!ptr is the same as (ptr != 0), and the 0 would be converted to a null
pointer.

Of course you meant ptr == 0.

 

[Hamiral]

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

Presumably the following will work:

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

if(!ptr) is very common, and everybody should undestand it.
But I personnally prefer being the most clear I can, so I always use
if(ptr == NULL) -- and in general I never use if(!anything)
Using NULL shows a bit more that you're dealing with pointers.

Ham

 

[Nick]

if(!ptr) is very common, and everybody should undestand it.
But I personnally prefer being the most clear I can, so I always use
if(ptr == NULL) -- and in general I never use if(!anything)
Using NULL shows a bit more that you're dealing with pointers.

! works well in some constructions:

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

 

[Seebs]

Of course you meant ptr == 0.

.... Yeah.

I think at this point I can safely say that no one is going to mistake
me for one of those natural wizards who never makes obvious mistakes, huh.

-s

 

[Hamiral]

! works well in some constructions:

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

Of course, I never test booleans like if(somebool == TRUE)...
I thought that was evident enough that people doing this just didn't
understand boolean expressions

Ham

 

[spinoza1111]

... Yeah.

I think at this point I can safely say that no one is going to mistake
me for one of those natural wizards who never makes obvious mistakes, huh..

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.

 

[spinoza1111]

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.

Everybody makes mistakes. We say one thing and mean as you did the
opposite, and our friends correct us. In programming, we code review,
pair program, and regression test (using suites like the suites I
presented for replace and strstr) to get the errors in code to
converge to zero.

In many cases (which programmers refuse to recognize because being
subservient to management is job one) errors are produced by forced
"Death March" development cycles driven by financial considerations
alone with no real programmer input. This seems to explain why
Schildt's book on C, like many other books before and since, had
nonzero errors: McGraw Hill decided it needed a Microsoft C centric
book and simply didn't give Schildt enough time.

But in your case, Mr. Seebach, you make silly errors frequently, and
each time you tell us that you get the trivial things wrong but
important things right. But then you post code (pseudo.c) after two
months, you say, in development in which ack and nak, putatively valid
responses, fall through to an error report and a variable is used with
no initial value whatsoever.

This would still be forgiveable but for your attack on Schildt, and
your calling a Apress colleague insane and a moron based on errors
found in code he'd submitted for review, where he fixed, documented
and credited those errors immediately, which you have NOT done in the
case of pseudo.c.

 

[Anand Hariharan]

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.

- Anand

 

[Nick Keighley]

Of course you meant ptr == 0.

which is why I don't use the !ptr form, I find it too error prone...

 

[Dr Malcolm McLean]

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.

"If pling pointer, do something"

 

[Nick Keighley]

! works well in some constructions:

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

I'm fine with using booleans this way, just not pointers

if (!ptr), doesn't read as "if not pointer". I suppose I could read
it as "if null-pointer"

 

[Ben Bacarisse]

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".

 

[spinoza1111]

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?

 

[spinoza1111]

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.

I would code if (!ptrToString) { ... } or if (!ptrString)...

Rolls off the tongue:

If not pointer to string
Do something
Otherwise, guys,
Do something else

If not pointer string
Don't worry about a goddamn thing
We will do something sensible
Otherwise something which at a minimum is not reprehensible.

Seriously, the usual crap code I see hear is unusable orally in
structured walkthroughs and pair programming.

If p can't you c
Any flies on me