if(a);

[Antoine Leca]

It appears a number of posters in comp.lang.c did miss my idea. I am sorry
to answer my own post, but this appears to me as the most simple solution to
avoid more useless posts.

[fu2 comp.std.c only]

This means that the answers only went to comp.std.c, they did NOT go to
comp.lang.c. I am sorry I took fro granted this was known.
This message is NOT redirected, so the answers will be shown on both groups.

The type of the octal signed int literal 0 [...]

Sorry to nit-pick: what is the reasonning to add "octal" above?

This is the question ('reasonning') I asked, and I did not see the answer
for it yet. But please keep reading before hitting the "Respond" button...

(I will not argue that 0 is not an octal constant, it is,

In other words, I made perfectly (?) clear I knew 0 is an octal constant,
which happens to be one of the 3 forms of integer constants. My point is,
the important fact here is that 0 is a constant of value 0. Not the way it
is written.

By the way:
"a single digit less than 8 is octal, by definition."
Well, yes, but what does it buy here? An octal constant begins with a 0,
followed by any number (including none) of octal digits. Here, there are
none.




If the original question does not appear clear, here is another way to ask
it:

if (a == 0)

...where a is any scalar type, the following will occur.

The type of the octal signed int literal 0 will be compared to the
type of 'a'.

What is different if we are reasonning on:

if( a == 0x0 )


NOW you can press the Respond button.


Antoine

 

[Antoine Leca]

En [email protected], Mark F. Haigh va
escriure:

You misrepresent your style opinions as objective fact. Boo!

Where does Dan says he is "objective" here? And where are facts?

He just indicates _to the newbies_ that explicit comparisons with NULL for
pointers might be a good idea ("is preferrable"). This certainly can be
discussed (and is ;-)).

I for once will agree with him on this particular one, because I do remember
the couple of times this caught me typing errors while compiling ;-).


Antoine

 

[Christian Bau]

Yes, but only according to your definition of readability, based on the
number of people on the planet who can correctly parse the given piece
of code. Apparently, in your opinion that's an appropriate definition
of readability in this context. But in some other people's opinion, it
may be less important how easily a completely newbie can misunderstand
our code, and more important how efficiently an experienced person can
read it.

In short, whether something is preferrable or not depends on who prefers it.

I personally wasted several days of my life because someone made code
more "readable" by changing

if (ptr == NULL)

to

if (ptr)

which did lead to a nastier case of undefined behavior. (A crash if the
computer was subsequently set to sleep for between 55 and 80 seconds,
but only if another perfectly correct code change in a completely
unrelated piece of code was present as well).

So I may be a bit prejudiced here, but I definitely prefer

if (ptr == NULL) or
if (ptr != NULL)

 

[CBFalconer]

.... snip ...

I personally wasted several days of my life because someone made
code more "readable" by changing

if (ptr == NULL)

to

if (ptr)

which did lead to a nastier case of undefined behavior. (A crash
if the computer was subsequently set to sleep for between 55 and
80 seconds, but only if another perfectly correct code change in
a completely unrelated piece of code was present as well).

Surely you mean to "if (!ptr)".

Or are you failing to blame some compiler code generation faults?
I see no way that could harm anything barring some nasty compiler
bugs. OTOH the possible idiocy of "someone"s mothers child is OT
here.

 

[Dan Pop]

Surely you mean to "if (!ptr)".

Nope, he meant what he wrote, otherwise the change wouldn't have broken
the code.

Dan

 

[James Kuyper]

Christian Bau wrote:
....

I personally wasted several days of my life because someone made code
more "readable" by changing

if (ptr == NULL)

to

if (ptr)

which did lead to a nastier case of undefined behavior.

That's bizarre - under what circumstance would that make a difference
over whether or not a piece of code had undefined behavior? I won't
claim that it's impossible, but I can't figure out how it could be possible.

 

[Jeremy Yallop]

That's bizarre - under what circumstance would that make a difference
over whether or not a piece of code had undefined behavior? I won't
claim that it's impossible, but I can't figure out how it could be possible.

#include <stddef.h>

int main()
{
void *ptr = &ptr;
if (ptr == NULL)
return *(int *)0;
else
return 0;
}

Jeremy.

 

[Xenos]

Surely you mean to "if (!ptr)".

Or are you failing to blame some compiler code generation faults?
I see no way that could harm anything barring some nasty compiler
bugs. OTOH the possible idiocy of "someone"s mothers child is OT
here.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

I believe he is saying that the person who modified the code accidentially
inverted the logic.

 

[Neil Cerutti]

I personally wasted several days of my life because someone made code
more "readable" by changing

if (ptr == NULL)

to

if (ptr)

which did lead to a nastier case of undefined behavior. (A
crash if the computer was subsequently set to sleep for between
55 and 80 seconds, but only if another perfectly correct code
change in a completely unrelated piece of code was present as
well).

Wow! I didn't think such was possible.

Nothing justifies the real cause of this error--changing one
style to the other when maintaining someone else's code.

 

[Ben Pfaff]

Christian Bau wrote:
...

That's bizarre - under what circumstance would that make a difference
over whether or not a piece of code had undefined behavior? I won't
claim that it's impossible, but I can't figure out how it could be
possible.

Those two statement fragments have exactly opposite behavior.

 

[Neil Cerutti]

Those two statement fragments have exactly opposite behavior.

Thanks for pointing that out. I missed that.

 

[James Kuyper]

Those two statement fragments have exactly opposite behavior.

Yes. I didn't notice that. I thought you were saying that he changed the
code from one form to a nominally equivalent form, and thereby caused a
failure because it wasn't fully equivalent. I didn't notice that the
conversion was completely wrong, and in one sense, that makes your point
about readability.

However, your problem was not due to the conversion itself, but due
solely to the fact that the conversion was implemented incorrectly.
Wouldn't you have had just as much trouble if he had changed it to:

if(ptr!=NULL)

Would you feel justified in criticizing use of the compound assignment
operators, if you'd been burned because some idiot had "improved" some
code by replacing

x = x+y;

with

y += x;

?

 

[Joona I Palaste]

Neil Cerutti <[email protected]> scribbled the following

"The barbarian seated himself upon a stool at the wenches side, exposing
his body, naked save for a loin cloth brandishing a long steel broad
sword..." --The Eye of Argon

That's one mighty loin cloth. Don't mess with it.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"And according to Occam's Toothbrush, we only need to optimise the most frequent
instructions."
- Teemu Kerola

 

[Wojtek Lerch]

I personally wasted several days of my life because someone made code
more "readable" by changing

if (ptr == NULL)

to

if (ptr)

which did lead to a nastier case of undefined behavior.

Did you waste your time because the code became less readable, or
because the change reversed the condition in the if()? If someone
broke your code by changing "if(ptr)" to "if(ptr==NULL)", would that
make you think that the former is better after all? ;-)

 

[Christian Bau]

Surely you mean to "if (!ptr)".

That's exactly the problem. He changed it from "if (ptr == NULL)" to "if
(ptr)".

 

[Christian Bau]

Did you waste your time because the code became less readable, or
because the change reversed the condition in the if()?

The time was wasted because the bug caused problems in some completely
different code, that was executed at a completely different time, and
only showed up in a situation where all my debugging tools wouldn't
work. And the problem was found only three months later, because that
was when the code that the bug broke was first tested - so no connection
to the original change.

If someone
broke your code by changing "if(ptr)" to "if(ptr==NULL)", would that
make you think that the former is better after all? ;-)

No, of course not. "if (ptr == NULL)" is very readable. It is plain
english "if ptr is equal to the null pointer then...". "if(ptr)" is not
plain english: "If ptr is (something's missing here) then...".

 

[Wojtek Lerch]

No, of course not. "if (ptr == NULL)" is very readable. It is plain
english "if ptr is equal to the null pointer then...". "if(ptr)" is not
plain english: "If ptr is (something's missing here) then...".

Then how is the story about someone breaking your code relevant?...

 

[Mark McIntyre]

Christian Bau wrote:
...

That's bizarre - under what circumstance would that make a difference
over whether or not a piece of code had undefined behavior?

This must be one of those "whats the difference between a duck" questions.

char* ptr = NULL;
if(ptr)
printf("Null\n")
else
printf("%s\n",ptr);

 

[Brian Inglis]

The time was wasted because the bug caused problems in some completely
different code, that was executed at a completely different time, and
only showed up in a situation where all my debugging tools wouldn't
work. And the problem was found only three months later, because that
was when the code that the bug broke was first tested - so no connection
to the original change.

The code the bug broke was the changed if conditions.
If the changes were extensive and the testing adequate, the inverted
if conditions should have shown up immediately.
It's unreasonable to blame a style choice for bad code and inadequate
testing.

No, of course not. "if (ptr == NULL)" is very readable. It is plain
english "if ptr is equal to the null pointer then...". "if(ptr)" is not
plain english: "If ptr is (something's missing here) then...".

If a C programmer can't parse "if (!ptr)" as "if ptr == NULL" and
"if (ptr)" as "if ptr != NULL" [or "if (!n)" as "if n == 0" and
"if (n)" as "if n != 0"] then that programmer should eschew C.
These are common, established, old, C idioms, predating the flight of
former Pascal educators and programmers into the C programming
community, with little knowledge of existing C code and its idioms,
importing their broken approaches towards I/O, character, and string
processing, to name only a few areas.
Some of the C textbooks and their code examples are as bad as those by
Herb Schildt.

 

[Dave Hansen]

Christian Bau wrote:
In short, whether something is preferrable or not depends on who prefers it.

I personally wasted several days of my life because someone made code
more "readable" by changing

if (ptr == NULL)

to

if (ptr)

[...]
No, of course not. "if (ptr == NULL)" is very readable. It is plain
english "if ptr is equal to the null pointer then...". "if(ptr)" is not
plain english: "If ptr is (something's missing here) then...".

If a C programmer can't parse "if (!ptr)" as "if ptr == NULL" and
"if (ptr)" as "if ptr != NULL" [or "if (!n)" as "if n == 0" and
"if (n)" as "if n != 0"] then that programmer should eschew C.

Apparently, that's the point. At least one programmer (and several
others who responded to this message a little too quickly...) didn't
immediately notice that "if (ptr==NULL)" is not equivalent to
"if (ptr)".

FWIW, I don't have any hard and fast rules on this. Just subjective
ones. "if (p)" looks lonely, so I'd probably make it "if (p!=NULL)".
OTOH, I'd be more likely to use "if (p && p->status==OK)" rather than
"if (p!=NULL && p->status==OK)". I'm unlikely to use "if (!p)" at all
-- I don't like double negatives, especially when one is implied...

Regards,

-=Dave