How should I test for a null pointer?
Mark Hobley
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.
--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/
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
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Michal Nazarewicz
> 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?
Providing that ptr is a pointer (and a header defining NULL has been
included) all of the following are equivalent:
#v+
if (!ptr) { }
if (ptr == 0) { }
if (ptr == (void*)0) { }
if (ptr == NULL) { }
#v-
What's important is that zero in pointer context is a NULL pointer
regardless of the NULL pointer's representation in memory. Therefore,
it's a matter of coding style or your taste which method you use.
comp.lang.c FAQ (<URL:http://c-faq.com/index.html>) has some nice
answers regarding the NULL pointer. It appears to be down though.
> I am using C89, if that matters.
IIRC it does not.
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--
Dr Malcolm McLean
wrote:
> 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
>
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
> On 2010-03-21, Mark Hobley <markhob...@hotpop.donottypethisbit.com> wrote:
>
> > 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
> --
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
wrote:
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.
Fuck that shit.
pete
> The main issue is that NULL is ALLCAPS which gives it an emphasis it
> really shouldn't have
That's not an issue with anybody except you.
--
pete
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.]
--
Ben.
Barry Schwarz
>On 2010-03-21, Mark Hobley <markh...@hotpop.donottypethisbit.com> wrote:
>> 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.
Of course you meant ptr == 0.
>
>In short, no matter what pattern of bits in memory represents a "null
>pointer", it compares equal to zero, and is thus "false".
>
>-s
--
Remove del for email
Hamiral
> How should I test for a null pointer within a C program?
>
> Presumably the following will work:
>
> if ( ptr == NULL ) { 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
! works well in some constructions:
"if(!done)", for example, reads as "if not done".
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
pete
> Hamiral <ham...@hamham.com> writes:
>
>> Mark Hobley wrote:
>>> 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.
I also use NULL when testing pointers, for the same reason.
and I use '\0' when testing for a null byte char.
>
> ! works well in some constructions:
>
> "if(!done)", for example, reads as "if not done".
if (!X) works well when (X) is boolean in nature,
such as when (X) is a ctype character testing function.
if (!isalnum(c))
if (!isspace(c))
--
pete
Seebs
> On 21 Mar 2010 09:31:10 GMT, Seebs <usenet...@seebs.net> wrote:
>>!ptr is the same as (ptr != 0), and the 0 would be converted to a null
>>pointer.
> 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.
Hamiral
> Hamiral <ham...@hamham.com> writes:
>
>> Mark Hobley wrote:
>>> 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.
>
> ! 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
> On 2010-03-21, Barry Schwarz <schwa...@dqel.com> wrote:
>
> > On 21 Mar 2010 09:31:10 GMT, Seebs <usenet-nos...@seebs.net> wrote:
> >>!ptr is the same as (ptr != 0), and the 0 would be converted to a null
> >>pointer.
> > 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.
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.
>
> -s
> --
spinoza1111
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
Hobley) wrote:
> How should I test for a null pointer within a C program?
>
> Presumably the following will work:
>
>
> 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
> On 21 Mar 2010 09:31:10 GMT, Seebs <usenet-nos...@seebs.net> wrote:
> >On 2010-03-21, Mark Hobley <markhob...@hotpop.donottypethisbit.com> wrote:
> >> 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.
>
> Of course you meant ptr == 0.
>
> >In short, no matter what pattern of bits in memory represents a "null
> >pointer", it compares equal to zero, and is thus "false".
which is why I don't use the !ptr form, I find it too error prone...
Dr Malcolm McLean
wrote:
Nick Keighley
> Hamiral <hami...@hamham.com> writes:
> > Mark Hobley wrote:
> >> 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.
>
> ! 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
FWIW: "if not ptr" where I usually vocalise "ptr" as "pointer".
--
Ben.
spinoza1111
Why not spell it out as I do consistently in my "convoluted" code
after my pre-Szymonyi Hungarian?
>
> --
> Ben.
spinoza1111
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
>
> - Anand
Keith Thompson
I read it as "if not ptr" or "if not pointer". I have to mentally
redefine the usual meaning of "not" for this to make sense. It's not
a real problem, but personally I prefer "if (ptr == NULL)".
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Seebs
> I read it as "if not ptr" or "if not pointer". I have to mentally
> redefine the usual meaning of "not" for this to make sense. It's not
> a real problem, but personally I prefer "if (ptr == NULL)".
Oddly, that fits my sense of "not", so it doesn't require redefinition to
me. I don't see a cognitive difference between:
x = count(kitties);
if (x) {
}
and
x = ptr_to_kitties();
if (x) {
}
They're both doing something if there were kitties.
-s
--
Julienne Walker
Why spell it out when the abbreviation is commonly known? In the case
of a subjective and supremely trivial matter, it's best to simply let
people do what they want and focus on more important issues. Pick your
battles unless you have nothing better to do than fight for fun.
For questions like the OP's, the best you can do is collect a number
of personal opinions and reach no conclusion. As such, I'll add to the
noise with my preference of being explicit when the object isn't
strictly boolean:
if ( ptr == NULL ) { /* ... */ }
With "ptr" as a generic placeholder for a more informative name. For
boolean objects it's a different matter:
if ( !done && is_valid ) { /* ... */ }
Anand Hariharan
> Anand Hariharan <mailto.anand.hariha...@gmail.com> writes:
> > On Mar 21, 3:08 am, markhob...@hotpop.donottypethisbit.com (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.
>
> I read it as "if not ptr" or "if not pointer". I have to mentally
> redefine the usual meaning of "not" for this to make sense. It's not
> a real problem, but personally I prefer "if (ptr == NULL)".
>
I suppose that sounds very similar to "if naught pointer" or "if
nought pointer" which is close enough to the actual semantics?
Dr Malcolm McLean
>
> Why spell it out when the abbreviation is commonly known?
>
for a pointer.
Now imagine you want to do, the following, write a qsort() replacement
that passes a pointer to the comparision function (as well as the two
data pointers), in order to allow for context-dependent comparisions
without using a global.
I'd write that as
void qsort2(void *data, int N, size_t s, int (*compfunc)(const void
*e1, const void *e2, void *ptr), void *ptr);
However "ptr" is banned. So "pointer" is an acceptable substitute.
Ben Pfaff
> Quite a few coding standrards say that "ptr" is an unacceptable name
> for a pointer.
[...]
> However "ptr" is banned. So "pointer" is an acceptable substitute.
It's hard for me to imagine why "ptr" would be banned and not
"pointer". It's quite clear that "ptr" stands for "pointer" and
it is a few characters shorter.
--
"A lesson for us all: Even in trivia there are traps."
--Eric Sosman
Stephen Sprunk
> On 21 Mar, 18:43, Nick <3-nos...@temporary-address.org.uk> wrote:
>> Hamiral <hami...@hamham.com> writes:
>>> Mark Hobley wrote:
>>>> 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)
The "if (ptr == NULL)" construction looks excessively verbose to me,
though I wouldn't bother changing it if I ran across it--unless the
project style guide said it was wrong, of course. I always write "if
(!ptr)" myself, and I've never had anyone reject it in a code review;
even if one doesn't like that form, one has to admit it's idiomatic.
>>> Using NULL shows a bit more that you're dealing with pointers.
True, but IMHO the pointer-ness of the variable should be obvious from
either naming or context; if not, you need more than little tricks like
that to fix the code.
>> ! 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"
I actually do pronounce "if (!ptr)" as "if not pointer"; I've seen the
construction so many thousands of times it makes sense to me when said
that way. Such is the power of following common idioms.
One could also read it as "if not valid pointer", but that's not
technically correct since ptr could be indeterminate, i.e. neither valid
nor null. Boolean operators tend to generate such false dichotomies all
over the place.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
William Ahern
But as pointed out elsethread (ptr) is equivalent to (ptr != 0), which is a
boolean expression. An if statement condition is a boolean expression by
definition.
I'll sometimes use (ptr == NULL) or like, but not because `ptr' is a
pointer; rather because `ptr' is a pointer _and_ it's a distinction that for
some exceptional reason should be highlighted. But in general it doesn't
need to be highlighted. In both the literal and practical context of an if
condition the semantic is boolean anyhow. Object types don't usually matter.
OTOH, I'll make use of all three idioms for integral zero--0, 0x00, and
'\0'--because my code often mixes use of zero-terminated and binary strings,
and I personally appreciate the subtle signaling when bouncing around
different areas of my projects. So, I'm not averse to certain coding
affectations. I just don't think the alternatives are more clear than plain
0. To the contrary, they sometimes give me pause, which is one of the effects
I want. If I don't want that effect, I don't do that.
Seebs
> On Mar 22, 11:20 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
>> Why not spell it out as I do consistently in my "convoluted" code
>> after my pre-Szymonyi Hungarian?
(I just had to quote that, because WTF. "Hungarian" is known as that
because it was named after Szymonyi.)
> Why spell it out when the abbreviation is commonly known?
Significantly:
* Human readers make more mistakes on longer words.
* Abbreviations help people read quickly and accurately.
So there's a lot to be said for picking consistent abbreviations.
The loop index "i" is not just some kind of short-cut; it improves
reliability and legibility of code.
> In the case
> of a subjective and supremely trivial matter, it's best to simply let
> people do what they want and focus on more important issues. Pick your
> battles unless you have nothing better to do than fight for fun.
Consider to whom you were responding.
Ersek, Laszlo
> On 2010-03-22, Julienne Walker <happy...@hotmail.com> wrote:
>> On Mar 22, 11:20 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
>>> Why not spell it out as I do consistently in my "convoluted" code
>>> after my pre-Szymonyi Hungarian?
>
> (I just had to quote that, because WTF. "Hungarian" is known as that
> because it was named after Szymonyi.)
(Hungarian guy here.) That's actually "Simonyi". It's pronounced
"scimogni" if you read Italian, or "shimonyi" in English, the "ny" being
pronounced like in Banyan VINES.
http://en.wikipedia.org/wiki/Charles_Simonyi
http://en.wikipedia.org/wiki/Hungarian_ny
lacos
(on topic as usual)
Seebs
> (Hungarian guy here.) That's actually "Simonyi". It's pronounced
> "scimogni" if you read Italian, or "shimonyi" in English, the "ny" being
> pronounced like in Banyan VINES.
Whoops! I'm very sorry. I even knew that looked funny, but in an
inexplicable moment of madness, I thought I'd just assume that Nilges
had gotten a fact right.
I have no idea why I thought that.
I should probably have just trusted my instinct to go look up the spelling,
especially in context.
Hamiral
> Hamiral <ham...@hamham.com> wrote:
>> Nick wrote:
>>> Hamiral <ham...@hamham.com> writes:
>>>
>>>> Mark Hobley wrote:
>>>>> 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.
>>> ! 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 ;)
>
> But as pointed out elsethread (ptr) is equivalent to (ptr != 0), which is a
> boolean expression. An if statement condition is a boolean expression by
> definition.
But ptr alone is not a boolean expression. It's a pointer, which should
be (to my mind) be tested against NULL. (ptr == NULL) is a boolean
expression. Using (ptr == NULL) clearly shows that you're dealing with a
pointer, whereas (!ptr) doesn't.
I meant that booleans variables (things like ok, done, etc) should not
be tested against TRUE or FALSE.
Ham
Hamiral
I read it "if not pointer", which doesn't make sense to me. I prefer
reading "if pointer is not assigned" for if(ptr == NULL)
Ham
William Ahern
> William Ahern wrote:
> > But as pointed out elsethread (ptr) is equivalent to (ptr != 0), which is a
> > boolean expression. An if statement condition is a boolean expression by
> > definition.
> But ptr alone is not a boolean expression. It's a pointer, which should
> be (to my mind) be tested against NULL. (ptr == NULL) is a boolean
In `if (ptr) { ... }' ptr is a boolean expression because an if statement
conditional must be boolean.
So, for instance, with this code
my $a = 0;
my $b = 42;
printf "%d\n", ($a || $b);
Perl should print "42".
But in C
int a = 0;
int b = 42;
printf("%d\n", ($a || $b));
you should just get "1".
But then, you say, that's because of the || operator. Well, something along
the same lines can be said for any expression in an if statement, no matter
whether there are other operators or not.
AFAIK, C# requires boolean expressions in if conditions, and even more so
you can't do things like `if (42) { ... }'. C requires boolean expressions,
too. But, in C the expression is made boolean by its context, similar to the
way using the || operator reduces the values to, effectively, boolean
values. In other words, the _type_ of the object in the expression doesn't
matter; the object is made to behave as a boolean regardless of the type
(though perhaps in a type-specific manner).
> expression. Using (ptr == NULL) clearly shows that you're dealing with a
> pointer, whereas (!ptr) doesn't.
But why does it matter that it show you're dealing with a pointer? You could
just as well use some naming convention that also shows you're dealing with
a pointer.
When it _does_ matter, then I'll use that notation. When it doesn't--and it
normally doesn't--using alternative syntax to convey the same meaning--
boolean value--is cost, not a benefit, IMO.
Dr Malcolm McLean
>
> It's hard for me to imagine why "ptr" would be banned and not
> "pointer". It's quite clear that "ptr" stands for "pointer" and
> it is a few characters shorter.
>
standard where "pointer" was banned as a variable name, but I've heard
of plenty where "ptr" was so prohibited.
Phil Carmody
> William Ahern wrote:
>> An if statement condition is a boolean expression by definition.
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.
> But ptr alone is not a boolean expression. It's a pointer, which
> should be (to my mind) be tested against NULL. (ptr == NULL) is a
> boolean expression. Using (ptr == NULL) clearly shows that you're
> dealing with a pointer, whereas (!ptr) doesn't.
Then name your variables sensibly enough that you know ptr is a
pointer without having to throw redundant operands into your
conditions.
> I meant that booleans variables (things like ok, done, etc) should not
> be tested against TRUE or FALSE.
That I agree with, but as the if() tests them against the only false
value, 0, anyway, there's no point in going out of your way to collapse
the expression onto a boolean one unnecessarily.
Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1
Dr Malcolm McLean
>
> So there's a lot to be said for picking consistent abbreviations.
> The loop index "i" is not just some kind of short-cut; it improves
> reliability and legibility of code.
>
i in Matlab because it thinks you mean root minus one), but it seems
obvious that short conventional symbols (x, y, i, N, ptr, str, theta,
t, temp) are better than long names that form English words. The
reason is that expressions can get fairly complex.
I use ii, iii, iv, v for inner loops. However j, k, l is more normal.
I use j when I need a second counter for the same level of loop, eg if
we need to count backwards as well as forwards over an array.
Keith Thompson
> Hamiral <ham...@hamham.com> wrote:
>> William Ahern wrote:
>> > But as pointed out elsethread (ptr) is equivalent to (ptr != 0),
>> > which is a boolean expression. An if statement condition is a
>> > boolean expression by definition.
>
>> But ptr alone is not a boolean expression. It's a pointer, which should
>> be (to my mind) be tested against NULL. (ptr == NULL) is a boolean
>
> In `if (ptr) { ... }' ptr is a boolean expression because an if statement
> conditional must be boolean.
No, the expression in an if statement merely needs to be a scalar.
C99 6.8.4.1 The if statement:
Constraints
The controlling expression of an if statement shall have
scalar type.
Semantics
In both forms, the first substatement is executed if the
expression compares unequal to 0.
where "both forms" refers to if vs. if-else.
Prior to C99, C didn't even have boolean expressions.
My own personal preference is that the expression in an if statement
should be, in some sense, *logically* boolean. That is, the
expression should represent a false/true condition; if it evaluates to
zero, the condition is false, and if it evaluates to any non-zero
value, the condition is true, with no meaningful distinction among
different non-zero values.
If there is such a distinction, I prefer to explicitly compare the
result to zero, so that the result of that comparison is "logically
boolean". Thus:
if (ptr !== NULL) /* different non-null pointers are distinct */
if (x != 0.0)
if (c != '\0')
if (count != 0)
if (strcmp(s1, s2) != 0) /* distinct non-0 values mean different things */
if (done)
if (isdigit(c)) /* logically boolean, even if it's neither 0 nor 1 */
Again, this is nothing more than my own personal preference.
I understand and accept that it's not supported by the langauge
standard, and that that not everyone shares it.
Keith Thompson
> Hamiral <ham...@hamham.com> writes:
>> William Ahern wrote:
>>> An if statement condition is a boolean expression by definition.
>
> 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.)
[...]
Keith Thompson
ptr = NULL; /* ptr has now been assigned */
if (ptr == NULL) ... /* ? */
spinoza1111
> On 2010-03-22, Julienne Walker <happyfro...@hotmail.com> wrote:
>
> > On Mar 22, 11:20 am,spinoza1111<spinoza1...@yahoo.com> wrote:
> >> Why not spell it out as I do consistently in my "convoluted" code
> >> after my pre-Szymonyi Hungarian?
>
> (I just had to quote that, because WTF. "Hungarian" is known as that
> because it was named after Szymonyi.)
As I have said, Charles Szymonyi stole this idea from his tenure at
IBM. "Hungarian" notation in the sense of a systematic prefix was in
use as early as 1962, for it appears in a book on coding standards
that was published in 1963 by Dick Brandon ("Management Standards for
Data Processing"), a book I used to own.
[I got the original reference wrong: the book was published in 1963,
not 1962 and although Dick Brandon was part of the Diebold group, he
and not Diebold was the author.]
That book showed a method for indicating the type and usage of
assembler language symbols in IBM 1401 that was later used in IBM 360
series Basic Assembler Language as a standard, and Szymonyi apparently
stole this idea and used it unethically as the basis of a PhD thesis
where a PhD thesis must be original work. Szymonyi worked for a while
at IBM after escaping Hungary, but was as maladjusted there as he was
under Goulash Communism.
I was already using it as a programmer and manager at Roosevelt
University in 1973.
However, one reason why I am happy, today, to be out of the field is
the lack of simple ethics of people like you and Szymonyi. I believe
you, Dweebach, submitted pseudo.c here to get your poorly written
(fallthrough case) C code fixed on behalf of Wind River Systems by
slaves.
This starts in the lead comment, where you at one and the same time
copyright the code on behalf of Wind River and then say it's a GNU
public license. If you knew your job, you'd know that copyright and
copyleft are incompatible, as incompatible as "clear" and "wrong".
>
> > Why spell it out when the abbreviation is commonly known?
>
> Significantly:
>
> * Human readers make more mistakes on longer words.
No, just ADHD dweebs.
> * Abbreviations help people read quickly and accurately.
Abbreviations are too local to languages and cultures. We can in a
globalized world expect programmers world wide to have command of the
English I teach today, which is world received English and rather
different from American English: for example, you don't say
"Manchester United wins", you say "Manchester United win", since a
football team is eleven lads. Therefore it is culturally insensitive
and productive of incomprehensible code to use abbreviations based on
American English.
>
> So there's a lot to be said for picking consistent abbreviations.
> The loop index "i" is not just some kind of short-cut; it improves
> reliability and legibility of code.
>
> > In the case
> > of a subjective and supremely trivial matter, it's best to simply let
> > people do what they want and focus on more important issues. Pick your
> > battles unless you have nothing better to do than fight for fun.
>
> Consider to whom you were responding.
>
> -s
> --
> Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
spinoza1111
Sounds like a Yorkshire joke: salesman pokes his head into an office
in Manchester: "aught?" Manager replies "nought!"
If you use naught, American programmers won't understand you, if that
bothers you.
spinoza1111
> On Mar 22, 11:20 am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
>
>
>
>
> > On Mar 22, 11:19 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> > > Anand Hariharan <mailto.anand.hariha...@gmail.com> writes:
> > > > On Mar 21, 3:08 am, markhob...@hotpop.donottypethisbit.com (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.
> of a subjective and supremely trivial matter, it's best to simply let
> people do what they want and focus on more important issues. Pick your
> battles unless you have nothing better to do than fight for fun.
Julienne, I am not "fighting for fun". There are some very evil things
going on in this newsgroup. Real thugs and head cases (Colonel Harlan
Sanders and Reid) are coming in here ONLY to savage people because
they are twisted head cases and closet queers. Seebach and Wind River
seem to be here to steal intellectual production from (unwitting)
slaves in order to fix, without credit or financial compensation,
amateurish errors in Seebach's code. Seebach is calling me "insane"
and a "moron" for making errors while consistently posting code
snippets and code ridden with errors he cannot fix. Heathfield is
still disrupting conversations possibly in the employ of a publisher
who jailed a friend of mine in Chicago several years ago when she
tried to get money owed her.
One reason I left the field was that in 1980 I joined a company in
which the evil was plain, but everybody, especially female employees,
spoke in dulcet tones and looked the other way when whistle blowers
were escorted from the building. I am too old and yet too employable
in other fields than programming to not speak out here.
>
> For questions like the OP's, the best you can do is collect a number
> of personal opinions and reach no conclusion. As such, I'll add to the
> noise with my preference of being explicit when the object isn't
> strictly boolean:
>
> if ( ptr == NULL ) { /* ... */ }
>
> With "ptr" as a generic placeholder for a more informative name. For
> boolean objects it's a different matter:
>
> if ( !done && is_valid ) { /* ... */ }
Basically, I prefer my pre-Szymonyi Hungarian standard (ptrIndex1...).
This is because it reconciles left-brain thinking (in the prefix) with
right brain thinking in the more evocative suffix that can be
pronounced.
Michael Foukarakis
> On Mar 22, 3:22 am, Seebs <usenet-nos...@seebs.net> wrote:
>
> > On 2010-03-21, Barry Schwarz <schwa...@dqel.com> wrote:
>
> > > On 21 Mar 2010 09:31:10 GMT, Seebs <usenet-nos...@seebs.net> wrote:
> > >>!ptr is the same as (ptr != 0), and the 0 would be converted to a null
> > >>pointer.
> > > 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.
>
> 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
> Phil Carmody <thefatphi...@yahoo.co.uk> writes:
>> Hamiral <ham...@hamham.com> writes:
>>> William Ahern wrote:
>>>> An if statement condition is a boolean expression by definition.
>>
>> 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,
Nick Keighley
> On Mar 22, 2:13 pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
<snip>
> > 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.
well if someone points them out to you, you can. "Someone" can include
careful desk checking, testing, super-lint or some formal method.
pete
i, j, k is more normal.
Using l as a variable name, is a crime.
--
pete
Julienne Walker
> On Mar 22, 11:55 pm, Julienne Walker <happyfro...@hotmail.com> wrote:
> > On Mar 22, 11:20 am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > > On Mar 22, 11:19 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> > > > Anand Hariharan <mailto.anand.hariha...@gmail.com> writes:
> > > > > On Mar 21, 3:08 am, markhob...@hotpop.donottypethisbit.com (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.
> > of a subjective and supremely trivial matter, it's best to simply let
> > people do what they want and focus on more important issues. Pick your
> > battles unless you have nothing better to do than fight for fun.
>
> 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.
> <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.)
--
Eric Sosman
eso...@ieee-dot-org.invalid
spinoza1111
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.
>
> --
> pete
spinoza1111
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.
>
> > > of a subjective and supremely trivial matter, it's best to simply let
> > > people do what they want and focus on more important issues. Pick your
> > > battles unless you have nothing better to do than fight for fun.
>
> > 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.
(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/
>
> > <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.
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
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
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. :P 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
--
Kenneth Brody
> On 2010-03-21, Mark Hobley<markh...@hotpop.donottypethisbit.com> wrote:
>> How should I test for a null pointer within a C program?
>
>
> 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 }
>
> pointer.
>
> pointer", it compares equal to zero, and is thus "false".
<nit>
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 )
</nit>
--
Kenneth Brody
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
eso...@ieee-dot-org.invalid
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.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Seebs
> On 3/23/2010 12:17 PM, Seebs wrote:
>> [...]
>> 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.
Richard Bos
> Hamiral <ham...@hamham.com> writes:
> > Mark Hobley wrote:
> >> 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.
>
> ! 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
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.
--
Flash Gordon
Peter Nilsson
> How should I test for a null pointer within a C program?
>
> 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
--
Peter
Eric Sosman
It deprives you of the obvious way to describe the bug in
void func(void) {
char *ptr;
strcpy (ptr, "Goodbye, cruel world!");
...
--
Eric Sosman
eso...@ieee-dot-org.invalid
pete
> 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 also have more trouble reading code
containing foreign language variable names
than I do reading code
containing meaningless single letter variable names.
But just the same, my preference for writing
is to use descriptive variable names.
--
pete
Keith Thompson
> Keith Thompson wrote:
>> ptr = NULL; /* ptr has now been assigned */
>> if (ptr == NULL) ... /* ? */
>
> 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.
spinoza1111
> On 2010-03-23, Michael Foukarakis <electricde...@gmail.com> wrote:
>
> > On Mar 22, 2:13 pm,spinoza1111<spinoza1...@yahoo.com> wrote:
> >> 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.
>
> 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. :P 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
> 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
> --
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.
--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/
Mark Hobley
> "If pling pointer, do something"
You think that was tricky! I remember the problems that I had trying to
describe operation of the windowing system verbally.
http://markhobley.yi.org/gui/supportscript/history.html
Ben Bacarisse
> Hamiral <ham...@hamham.com> wrote:
>> 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
You should name and shame. No language should be that clumsy!
> 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
You should never need to. 'if booleanvalue' should work in all but
the clumsiest programming languages.
> 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}
What benefit do these macros provide? You don't show them and I can't
guess.
--
Ben.
Mark Hobley
> What benefit do these macros provide? You don't show them and I can't
> guess.
They just provide a way of putting the words true or false within the
expression for the benefit of a casual human* debugger.
#define istrue(arg) (arg)
#define isfalse(arg) !(arg)
(It just saves the guy from having to think ... "hmmm, is true expressed as
a zero or non-zero value in this language?")
It seems odd to me to have a convention of zero to represent successful
completion, but to then use the value as false:
# This logic does not work in C, because success is false
if thisfunctionsucceeds() then
# blah blah blah
else
print "Damn! It's fucked."
# Note that our error handler is nicely positioned as a footnote
# below the main body of the the code
endif
That doesn't work in C, which means that to a human* reading the code, the
our error handler is now interrupting the flow as the program is read from
top down.
if thisfunctionfails() {
/* The error handler is in right in your face at the top of the code */
printf("Damn! It's fucked")
} else {
/* blah blah blah */
}
In assembly language we use a goto, but some programmers do not like these.
# Although assembly language also uses the same convention as C, the
# one line goto, and the lack of braces, makes the jump to the error
# handler unobtrusive
call ourfunction
jnz errorhandler # We use a goto here
# blah blah blah
Trying a similar trick in C gives us
if thisfunctionfails() {
goto errorhandler; /* It still looks messy */
} else {
/* blah blah blah */
}
Or we can have a really horrible construct:
if thisfunctionfails() { goto errorhandler; } else {
blah blah blah
}
Note that blah blah blah is based on success, but the if statement above was
testing for failure! Yuck !
* Although I am human, I don't alway appear to be.
Nick Keighley
> On 2010-03-23, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> > On 3/23/2010 12:17 PM, Seebs wrote:
> >> 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.
Thank you but...
...that's a well known problem
...its always done that
...why would anyone do that?
...customers don't do that
...that's bound to happen if you do that
...we'll change the handbook
...that's so old we should just close it
my time in system test wasn't wasted
Nick Keighley
> Keith Thompson wrote:
> > 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 ?
"if you call a tail a leg how many legs does a dog have? Four, because
calling a tail a leg doesn't mean it is a leg"
Lincoln, I believe
Bob Doherty
The RSX develpment team for PDP-11 when confronted with something they
didn't wish to address, because the complainer was an idiot, or the
complainer was correct but for political reasons they couldn't do
anything about it, or for some other reason was a simple
...Noted.
--
Bob Doherty
Ben Bacarisse
> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>> What benefit do these macros provide? You don't show them and I can't
>> guess.
>
> They just provide a way of putting the words true or false within the
> expression for the benefit of a casual human* debugger.
>
> #define istrue(arg) (arg)
> #define isfalse(arg) !(arg)
>
> (It just saves the guy from having to think ... "hmmm, is true expressed as
> a zero or non-zero value in this language?")
Ah. Sorry, but I think that's a bad idea. It all comes under the
category of tying to guess what kind of information deficit the reader
has. Why assume they don't know one of the most basic things about
the language they are reading? Why do anything to delay them
acquiring this knowledge? (The argument seems to be they will be
happy to skip over the newly clarified conditions rather figure out
how C does ifs).
For readers who do know what a C 'if' does you add a level of
obfuscation. The reader immediately thinks "what is this programming
doing with C's idea of true/false conditions that they need a macro?
Oh, I see, nothing at all".
All languages have foibles, but C also has a macro processor and the
combination tempts people learning C to use the latter to tidy up the
former. I don't think that is ever a good idea.
> It seems odd to me to have a convention of zero to represent successful
> completion, but to then use the value as false:
>
> # This logic does not work in C, because success is false
> if thisfunctionsucceeds() then
> # blah blah blah
> else
> print "Damn! It's fucked."
> # Note that our error handler is nicely positioned as a footnote
> # below the main body of the the code
> endif
OK, you want the error case second. I'll go with that for the moment...
> That doesn't work in C, which means that to a human* reading the code, the
> our error handler is now interrupting the flow as the program is read from
> top down.
>
> if thisfunctionfails() {
>
> /* The error handler is in right in your face at the top of the code */
> printf("Damn! It's fucked")
>
> } else {
>
> /* blah blah blah */
> }
So why write it that way if you want the error case second? This is
so obious a question that I must have missed your point. What is it
about C that makes you think you forced into doing it the way you
don't like?
> In assembly language we use a goto, but some programmers do not like these.
>
> # Although assembly language also uses the same convention as C, the
> # one line goto, and the lack of braces, makes the jump to the error
> # handler unobtrusive
>
> call ourfunction
> jnz errorhandler # We use a goto here
> # blah blah blah
>
> Trying a similar trick in C gives us
>
> if thisfunctionfails() {
> goto errorhandler; /* It still looks messy */
> } else {
> /* blah blah blah */
> }
>
> Or we can have a really horrible construct:
>
> if thisfunctionfails() { goto errorhandler; } else {
> blah blah blah
> }
All you C ifs are missing brackets round the condition, by the way.
What is it that you have against
if (!thisfunctionfails()) {
blah blah blah
}
else /* error case */;
? Personally, I'd write the function to be "positive" i.e. to return
non-zero on success, but I agree that there are some written the other
way round. These should not have a name that suggests they might be
tested logically.
<snip>
--
Ben.
Dr Malcolm McLean
wrote:
>
> It seems odd to me to have a convention of zero to represent successful
> completion, but to then use the value as false:
>
err = functionthatmightfail(str, x, y);
if(err)
{
/* clean up failure */
}
The problem with
if( functionthatmighfail(str, x, y) )
is that it makes it look as if the purpose of functionthatmightfail()
is to return a value. In the first case it's obvious that it's
modifying the string str based on some values x, y.
Seebs
> Thank you but...
>
> ...that's a well known problem
> ...its always done that
> ...why would anyone do that?
> ...customers don't do that
> ...that's bound to happen if you do that
> ...we'll change the handbook
> ...that's so old we should just close it
>
> my time in system test wasn't wasted
Ugh.
I still remember the horrors of doing testing for people who Just
Didn't Care. "When you use this feature, the software coredumps."
"Don't use that feature." "$BIG_CUSTOMER is already using the feature
in production, and they want it fixed." "We've removed it from the
next version."
The scary thing? The average cost of a program crash was somewhere
around $50k. This did not appear to factor into evaluations, though,
because it was *customers* paying the $50k, not *developers*.
Seebs
>
> ...that's a well known problem
> ...its always done that
> ...why would anyone do that?
> ...customers don't do that
> ...that's bound to happen if you do that
> ...we'll change the handbook
> ...that's so old we should just close it
>
> my time in system test wasn't wasted
Ugh.
I still remember the horrors of doing testing for people who Just
Didn't Care. "When you use this feature, the software coredumps."
"Don't use that feature." "$BIG_CUSTOMER is already using the feature
in production, and they want it fixed." "We've removed it from the
next version."
The scary thing? The average cost of a program crash was somewhere
around $50k. This did not appear to factor into evaluations, though,
because it was *customers* paying the $50k, not *developers*.
-s
Hamiral
> if istrue(booleanvalue) {dosomething}
>
> and
>
> if isfalse(booleanvalue) {dosomething}
That reminds me that (sorry it's Pascal not C) ;)
(*---------------------------------------------------------------------------
Procedure: IsTrue
Author: jed
Date: 26-Aug-2003
Description: useful for determining the boolean result of an expression
---------------------------------------------------------------------------:*)
function IsTrue(Expression: TExpression): Boolean;
var
ResultHasBeenSet: Boolean;
begin
Result:=(Random(2)=0)=True;
ResultHasBeenSet:=False;
// if the expression is true then the result will be true, otherwise
(since the
// expression couldn't be true) the result will be false. There are
no other
// mathematical possibilities
begin
if (Expression=True) then
begin
Result:=True;
ResultHasBeenSet:=True;
end;
if (Expression=False) then
begin
Result:=False;
ResultHasBeenSet:=True;
end;
end;
// need to set the result if it hasn't been set yet, we'll randomly
decide true or false
// because there should be no bias.
if IsTrue(ResultHasBeenSet)=IsTrue(0=1)
then Result:=((Random(2)=Random(2))=True)
else Result:=(Result=True);
// P.S.
// This function could also be adapted to tell you if some
expression is false
// by prefixing the expression (or the result) with the 'not'
operator. You can
// find out more about the 'not' operator in the online help.
end;
Ham
Dr Malcolm McLean
>
> The scary thing? The average cost of a program crash was somewhere
> around $50k. This did not appear to factor into evaluations, though,
> because it was *customers* paying the $50k, not *developers*.
>
not the actual value to customers, is what determines the price ypu
get for it. So if customers' accpunting system isn't good enough to
pick up the money he loses on crashes, he gets cheaper buggy software
rather than more expensive reliable stuff.
(This reaches an extreme when the customer is the consumer. Virtually
all the major consumer goods companies have far more equity in brands
than in physical plant. Often more money goes on marketing the product
than in manufacturing it. The associations that the marketing people
create between the product and the customers' aspirations almost never
have any basis in physical reality - the same beer can be a womans'
drink in Europe, a manly drink in America.)
Nick Keighley
> > # FALSE and NOT FALSE is just nasty
> > if booleanvalue != FALSE # This looks really nasty. I wouldn't do
> > that
>
> You should never need to. 'if booleanvalue' should work in all but
> the clumsiest programming languages.
not all programming languages have booleans. Consider Coral-66
IF finished = TRUE THEN
terminate (link);
(syntax from memory!)
BruceS
<snip>
> ? Personally, I'd write the function to be "positive" i.e. to return
> non-zero on success, but I agree that there are some written the other
> way round. These should not have a name that suggests they might be
> tested logically.
As one more side-topic: I almost always prefer the reverse. If a
function succeeds, I don't care exactly *why* it succeeded. If it
fails, the reason for failure may be important and dictate the
behavior of the calling function---at least to the extent of logging
or reporting the error code. Of course, sometimes the fact of failure
is also enough (e.g. malloc and friends) to determine response.
I recall a system (VMS?) where the standard was to use even/odd to
indicate success/failure. We had a macro to weed out the success
codes, and universally ignored them. The errors codes, however, got
used.
Ben Bacarisse
> On Mar 24, 8:29 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> <snip>
>> ? Personally, I'd write the function to be "positive" i.e. to return
>> non-zero on success, but I agree that there are some written the other
>> way round. These should not have a name that suggests they might be
>> tested logically.
>
> As one more side-topic: I almost always prefer the reverse. If a
> function succeeds, I don't care exactly *why* it succeeded. If it
> fails, the reason for failure may be important and dictate the
> behavior of the calling function---at least to the extent of logging
> or reporting the error code. Of course, sometimes the fact of failure
> is also enough (e.g. malloc and friends) to determine response.
That's a perfectly sound way of doing things but it does tend to
prioritise the status rather than the value a function computes.
Computed results typically have to be returned via a pointer. When I
need an informative error status, I prefer that to the thing returned
via a pointer.
Yours is the style used by *nix system calls, but that is for sound
technical reasons (though they may now be historical) -- only a simple
result could be returned as the value, and the kernel got to validate
pointers used for larger computer values. Without these restrictions,
it would not be my first choice.
<snip>
--
Ben.
Kenneth Brody
> On 3/23/2010 12:17 PM, Seebs wrote:
>> 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."
Assuming, of course, that it's really a bug. As opposed to, say, a report
that says something to the effect of "IsLeap(2000) returns true".
--
Kenneth Brody
pete
The ones written the other way around,
should be capable of returning values which distinguish
between different modes of failure.
--
pete
Nobody
>> >!ptr is the same as (ptr != 0), and the 0 would be converted to a null
>> >pointer.
>>
>> Of course you meant ptr == 0.
>>
>> >In short, no matter what pattern of bits in memory represents a "null
>> >pointer", it compares equal to zero, and is thus "false".
>
>
> which is why I don't use the !ptr form, I find it too error prone...
Odd; That's why I don't use ptr==0 or ptr!=0.
"!=0" is a postfix no-op, while "==0" is a postfix negation. But (as
Seebs demonstrated) it's very easy to confuse the two.
If I want to invert "x", I'll write "!x"; if I want "x" without any
inversion, I'll just write "x".
If the value being tested was an actual C99 "bool", would you write:
if (x != false)
and:
if (x == false)
in preference to:
if (x)
and:
if (!x)
?
I wouldn't, and I wouldn't do it for pointers, either.
Keith Thompson
[...]
> If the value being tested was an actual C99 "bool", would you write:
>
> if (x != false)
> and:
> if (x == false)
>
> in preference to:
>
> if (x)
> and:
> if (!x)
>
> ?
Certainly not.
> I wouldn't, and I wouldn't do it for pointers, either.
That's where we differ. I wouldn't write "if (ptr == 0)", as you
mention in the text that I snipped; I'd write "if (ptr == NULL)".
I find "if (x)" clearer than "if (x != false)", at least if x is
logically a condition (i.e., it has a better name than "x").
I find "if (ptr != NULL") clearer than either "if (ptr != 0)"
or "if (ptr)".
YMMV, of course.
Flash Gordon
You must have been using a modern variant since you did not put single
quotes around the keyboards! Now stop giving me nightmares.
--
Flash Gordon
Yes, I've programmed and bug fixed (to a small extent) in Coral 66 even
though I never learned the language.
Nick Keighley
> I recall a system (VMS?) where the standard was to use even/odd to
> indicate success/failure.
it was VMS. I think an even value was an error so a program that
returned 0 caused a bizzre error to be reported by the shell. This was
a problem for some VMS C compilers.
Dr Malcolm McLean
This can be dangerous, because people who don't have much experience
in programming often don't realise that even the best programmers
continually make "idiotic" errors, like off by one errors in
calculating a loop or failing to check for a divide by zero.
August Karlstrom
> That's where we differ. I wouldn't write "if (ptr == 0)", as you
> mention in the text that I snipped; I'd write "if (ptr == NULL)".
>
> I find "if (x)" clearer than "if (x != false)", at least if x is
> logically a condition (i.e., it has a better name than "x").
>
> I find "if (ptr != NULL") clearer than either "if (ptr != 0)"
> or "if (ptr)".
>
> YMMV, of course.
I agree 100%.
Clear writing:
if (done) ...
if (p == NULL) ...
if (n != 0) ...
Obscure writing:
if (done != 0) ...
if (!p) ...
if (n) ...
/August
August Karlstrom
> If the value being tested was an actual C99 "bool", would you write:
>
> if (x != false)
> and:
> if (x == false)
>
> in preference to:
>
> if (x)
> and:
> if (!x)
No, I think we should write
if ((x != false) != false)
and
if ((x == false) != false)
...just to be sure.
/August
io_x
news:hoagea$fed$1...@news.eternal-september.org...
> 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?
i use all "esp", "sp", "s", "" because some macro definition
Nick Keighley
> On Mon, 22 Mar 2010 07:41:25 -0700, Nick Keighley wrote:
> >> >!ptr is the same as (ptr != 0), and the 0 would be converted to a null
> >> >pointer.
>
> >> Of course you meant ptr == 0.
>
> >> >In short, no matter what pattern of bits in memory represents a "null
> >> >pointer", it compares equal to zero, and is thus "false".
>
> > which is why I don't use the !ptr form, I find it too error prone...
>
> Odd; That's why I don't use ptr==0 or ptr!=0.
>
> "!=0" is a postfix no-op,
a rather bizzre way of looking at things. It looks like an infix
inequality operator to me...
> while "==0" is a postfix negation.
if you want to think that way go ahead. But it looks nothing like a
"negation" operator to me. And what does it mean to "negate" a
pointer?
> But (as
> Seebs demonstrated) it's very easy to confuse the two.
but we seem todisagree about what confused him...
> If I want to invert "x", I'll write "!x"; if I want "x" without any
> inversion, I'll just write "x".
I've never had a nedd to invert a pointer. Flip all the bits?
> If the value being tested was an actual C99 "bool", would you write:
>
> if (x != false)
> and:
> if (x == false)
>
> in preference to:
>
> if (x)
> and:
> if (!x)
>
> ?
no, but we are talking about pointers not bools. I'd use the same
codeif I were writing C89 code with x an int that was logically
boolean. bool is about the only useful addition to C99.
> I wouldn't, and I wouldn't do it for pointers, either.
a pointer is not a bool...
Nick Keighley
wrote:
my favourite bug report
"it doesn't fucking work"