if(a);

C

Christian Bau

"Wojtek Lerch said:
Then how is the story about someone breaking your code relevant?...

The break only happened because the code was less readable. It was
wrong, but it was not so obviously wrong that it was noticed. Changing
"if (ptr == NULL)" to "if (ptr != NULL)" would be a much more obvious
mistake; both versions are very readable and therefore it would have
been obvious that the change is incorrect.
 
R

Richard Bos

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

So... he obviously read "if (ptr == NULL)" _wrongly_, and this is proof
that that style is _easier_ to read than "if (!ptr)" would have been?
Bizarre.

Richard
 
C

Casper H.S. Dik

James Kuyper said:
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.

I think a reaction like this proves the point which is also well illustrated
by the original code chaneg: it's too easy to confuse the meaning of the
implied test with the opposite.

Casper
 
C

Casper H.S. Dik

James Kuyper said:
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:

Please reread your first paragraph.

Then realize why:

if (ptr != NULL)

is superior to
if (ptr)


Casper
 
A

Antoine Leca

En [email protected], Casper H.S. Dik va escriure:<James Kuyper answered, missing that the meaning changed, titled by the
words "undefined behaviour">
I think a reaction like this proves the point which is also well
illustrated by the original code chaneg: it's too easy to confuse the
meaning of the implied test with the opposite.

Which of course is more a proof that "rewriting to improve code readability"
is not always a good thing, rather than any demonstration about whatever
particular style.


Antoine
 
W

Wojtek Lerch

Christian Bau said:
The break only happened because the code was less readable. It was
wrong, but it was not so obviously wrong that it was noticed. Changing
"if (ptr == NULL)" to "if (ptr != NULL)" would be a much more obvious
mistake; both versions are very readable and therefore it would have
been obvious that the change is incorrect.

The break happened because someone read the old code and replaced it with
new code that had the opposite semantics. Obviously, he misunderstood
either what he read or what he wrote. How does that demonstrate that the
code he read was more readable than the code the wrote?

Of course, changing "if (ptr == NULL)" to "if (ptr != NULL)" would be a much
more obvious mistake, and so would changing "if(ptr)" to "if(!ptr)". But
the only thing that proves is that when you intend to change only the style,
it's possible to unintentionally change the meaning, too, whereas if you
don't intend to change the style or the meaning, you just leave the code
alone and there's no chance that you might break it.
 
D

Douglas A. Gwyn

Christian said:
The break only happened because the code was less readable. It was
wrong, but it was not so obviously wrong that it was noticed. Changing
"if (ptr == NULL)" to "if (ptr != NULL)" would be a much more obvious
mistake; both versions are very readable and therefore it would have
been obvious that the change is incorrect.

Readability of course is in the eye of the beholder.
Having said that, I will agree that writing if(ptr==NULL)
is better style than if(!ptr), for at least two reasons:
(1) ! is a logical "not" operator, and it is unnatural
to apply it to a pointer value (address).
(2) In order to understand the code snippet, one has to
mentally map it into if(ptr is a null pointer), which is
more directly expressed as if(ptr==NULL).
The less mental interpretation that is required, in
general, the easier the code is to read.
 
J

James Kuyper

Please reread your first paragraph.

Then realize why:

if (ptr != NULL)

is superior to
if (ptr)

Please re-read my first paragraph, and recognise that I acknowledged the
point you're making.
 
C

Casper H.S. Dik

Wojtek Lerch said:
The break happened because someone read the old code and replaced it with
new code that had the opposite semantics. Obviously, he misunderstood
either what he read or what he wrote. How does that demonstrate that the
code he read was more readable than the code the wrote?

I fail how someone can misinterpret:

if (ptr == NULL)

it's not difficult to see how someone can misconstrue the implicit operation
revered in:

if (ptr)

The fact that some (many?) people misread that this change was wrong
is ample proof that the second form is harder to read unless you can
come up with a concinving argument on how the first form can be
misinterpreted.

Casper
 
N

Neil Cerutti

Please reread your first paragraph.

Then realize why:

if (ptr != NULL)

is superior to
if (ptr)

At this point I should slink off with my tail between my legs,
but I do want to defend those of us who screwed this up by saying
that the context of this thread made me assume, without really
thinking about it, that the incident being explained would be
more relevent to the discussion that it turns out to be.

We're conditioned to assume, to gleen the meaning of things by
their context. Even though a native English speaker has an
everage vocabulary of 360,000 words, we don't know exactly what
they all mean instantly: we have to guess from context. We
compose sentences in the same way, rendering out-of-context
quotations meaningless, or even sometimes seeming to say the
opposite of what was meant. Similarly, we often don't easily
recognize familiar faces of people we know from one part of our
life if they pop up in another.

We did not get to see the code surrounding the error, which may
well have made it an obvious mistake, e.g.:

My foolish, working-code altering colleague changes this:

char *ptr = malloc(500);
if (ptr == NULL) {
return EXIT_FAILURE;
}

into this:

char *ptr = malloc(500);
if (ptr) {
return EXIT_FAILURE;
}

My guess is that close to 100% of the readers here would've
spotted *that* code defect.

The post had a similar context-subversive effect as the old joke:
"If a passenger airplane crashes exactly on the border between
Canada and the USA, where do they bury the survivors?"

In any case, I applaud the author. It was a good trick, and boy
is my face red. Lucky for you all, I'm not working on your
project. ;-)
 
M

Michael Wojcik

[Followups restricted to comp.lang.c, since I greatly doubt the committee
has any interest in altering the standard based on this thread.]

I think a reaction like this proves the point which is also well illustrated
by the original code chaneg: it's too easy to confuse the meaning of the
implied test with the opposite.

I believe you're wrong here, Casper, and Richard Bos is correct. The
maintainer read the explicit test and rewrote it as an implicit one.
Either he misread the explicit test or miswrote the implicit one; the
former seems far more likely[*], so this example fails to support the
thesis that the explicit test is less likely to cause a maintenance
error.

Of course, it does nothing to demonstrate that the *implicit* test is
any better. Even if it did, it's nothing more than anecdote, and as
an argument for anything would carry little weight.

* Why is a misreading of the original test more likely? Because I
assume that programmers tend to use the idioms they're most comfortable
with, and "if (ptr)" and its converse are very simple. I find it
unlikely that anyone would write "if (ptr)" believing that it evaluated
true if ptr was NULL - that's clearly against intuition. It's always
possible that the maintainer meant to write "if (!ptr)" but omitted the
exclamation point as a typo - but again this would say nothing about
the advantage of either style, since the same typo applies equally to
both.
 
A

August Derleth

It didn't take long to decide that I didn't want to spend the time
reading it, but I quickly scanned through and found the amusing bit at
the end: "An excellent proofreader has checked it for errors both
ommitted and committed." ^^^^ ^^^^^^^^^^^^^^^^^^^^^^

The "excellent proofreader" must have been sound asleep that day.

No, he was making sure the digital transcription matched the effect of the
printed page as far as was practicable. He wasn't to correct the
manuscript, but to ensure all of the manuscript's errors were present in
the HTML version. Bug-for-bug compatible, as it were. ;)

As for not wanting to read The Eye of Argon: That's probably the most
common response, but surely you weren't expecting worthy prose.
 
W

Wojtek Lerch

(Followups to comp.lang.c only)
The fact that some (many?) people misread that this change was wrong
is ample proof that the second form is harder to read unless you can
come up with a concinving argument on how the first form can be
misinterpreted.

No, it just proves that some people in these newsgroups didn't pay
enough attention to notice that the two lines of code have different
semantics. I think that this kind of mistake is forgivable in a
discussion about differences in readability, rather than in semantics,
between various styles of code.

The person from the story read the code that you claim is impossible to
misinterpret, and then *wrote* code that did the exact opposite. If
someone can misunderstand something as simple as "if(ptr)" when he's
writing it himself, I think that proves more about the person than it
does about the code. Perhaps he didn't even read what he wrote, and
therefore the *readability* of it was not involved at all? ;-)

Writing is different from reading. I suspect that it's much easier to
write "if(ptr=NULL)" when you mean "if(ptr==NULL)" than it is to write
"if(ptr)" when you mean "if(!ptr)". Some people say that it's therefore
better to write "if(NULL==ptr)"; some other people hate the English that
that translates to. There are multiple conflicting criteria and there's
no "objective" truth that everybody must accept unless they're stupid.
 
C

Christian Bau

So... he obviously read "if (ptr == NULL)" _wrongly_, and this is proof
that that style is _easier_ to read than "if (!ptr)" would have been?
Bizarre.

I think you've got that wrong.
 
D

Dave Hansen

So... he obviously read "if (ptr == NULL)" _wrongly_, and this is proof
that that style is _easier_ to read than "if (!ptr)" would have been?
Bizarre.

I wasn't there, don't know exactly what happened, and don't know the
people involved. However, this is usenet, so I'm going to reply
anyway. ;-)

I suspect it was more along the lines of "Here are some characters in
this source file that aren't necessary. Who cares if the code is
already written and is known to work? I'll change it to a form more in
the spirit of C. As in Cowboy. Coding Cowboy, that is, pardner.
I've read the standard, I know it's equivalent, there's no sense
wasting anybody's time (especially mine!) to test it..."

Regards,

-=Dave
 
L

lawrence.jones

In comp.std.c Casper H.S. Dik said:
it's not difficult to see how someone can misconstrue the implicit operation
revered in:

if (ptr)

Yes, it is. It's not difficult to see how someone can misconstrue the
implicit operation in:

if (strcmp(str, "ABC"))

because the implicit operation is exactly opposite to the intuitive
result, but:

if (ptr)

is such a common idiom that even novice C programmers are expected to
understand it and the implicit operation corresponds exactly to the
intuitive result (ptr actually points to something rather than being
NULL).

-Larry Jones

I wonder what's on TV now. -- Calvin
 
W

Wojtek Lerch

Douglas A. Gwyn said:
Readability of course is in the eye of the beholder.
Having said that, I will agree that writing if(ptr==NULL)
is better style than if(!ptr), for at least two reasons:
(1) ! is a logical "not" operator, and it is unnatural
to apply it to a pointer value (address).
(2) In order to understand the code snippet, one has to
mentally map it into if(ptr is a null pointer), which is
more directly expressed as if(ptr==NULL).
The less mental interpretation that is required, in
general, the easier the code is to read.

But if you have trained yourself to mentally map "if(ptr)" directly into
"if(ptr points to something)" and "if(!ptr)" into "if(ptr doesn't point to
anything)", those may sound even more natural and require less
interpretation than "ptr is equal to NULL, and since NULL is a special value
that doesn't point anywhere, ptr doesn't point anywhere, either", or "ptr is
not equal to NULL, and since the only thing other than NULL that we could
have set ptr to is the address of some object, ptr must be pointing to some
object".

:)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,142
Messages
2,570,820
Members
47,367
Latest member
mahdiharooniir

Latest Threads

Top