int a[5] .. difference between a and &a

[P.J. Plauger]

P.J. Plauger said:


Since it can, I'd have thought that to be a rather important thing to say.
Undefined behaviour *can* cause real effects in the real world, and I've
seen machines trashed by it. I suppose you have, too. And that's why it's
neither a quibble nor off the point to indicate to the OP that his
program's results are untrustworthy and that his first act should be to
correct his program.

Then tell him how to correct his program, if you want to be truly
helpful at least.

That is *one* of the things the OP needed education about, yes.

But you chose not to provide that education, or even suggest that
it might be needed.

<snip>

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Keith Thompson]

P.J. Plauger said: [...]

The interesting point here was
that two address calculations can yield the same value. That's what
the OP needed education about.

That is *one* of the things the OP needed education about, yes.

But you chose not to provide that education, or even suggest that
it might be needed.

Fortunately, as I'm sure Richard knows, there are plenty of other
posters in this group who are ready and willing to provide that
information.

 

[Richard]

P.J. Plauger said:

onkar said:

#include<stdio.h>
int main(int argc,char **argv){
int a[5]={1,2,3,4,5};
printf("%p\n%p\n",a,&a);
return 0;
}


gives me :
0xbfe837a0
0xbfe837a0

Invoking undefined behaviour can give any result whatsoever.

Seems to me that a decays to an int * while &a is int[5] *.

Well, int (*)[5], but yes. Neither is of type void *, however.

Both are well formed and happen to have the same address value,
just different types. The only thing undefined about this
program is that %p strictly speaking accepts just a void *,
which *might* have a different representation than int * or
int[5] *. Add the casts and I'll bet you get the same printout,
in a well formed program.

And what lesson will the OP draw from your apparent condoning of the cast
omission, I wonder?

That your quibble is off the point and about as useful as saying that

A frequent occurrence.

void main can set your house on fire. The interesting point here was
that two address calculations can yield the same value. That's what
the OP needed education about.

The more subtle point was that &a is well formed, despite widespread
confusion on the topic. (Witness the erroneous remarks by Sourceror.)
It took me three meetings of X3J11 to convince the committee that &a
should be well formed, despite the distracting misbehavior of Steve
Johnson's Portable C Compiler (which decayed arrays to pointers a bit
too eagerly).

And the pragmatic point is that the (void *) cast is indeed often
gratuitous in real-world code. Indeed, a couple of the more delicate
backward-compatibility features in Standard C depend on this common
pun. So telling a novice that two pointer values are equal only because
his program can give "any result whatever" is prissy and self serving.
It is certainly not edifying.

Well put.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

--

 

[Richard Heathfield]

P.J. Plauger said:

But you chose not to provide that education, or even suggest that
it might be needed.

That would have happened in Lesson 3 or thereabouts.

 

[Craig Franck]

P.J. Plauger said:

Since it can, I'd have thought that to be a rather important thing to say.
Undefined behaviour *can* cause real effects in the real world, and I've
seen machines trashed by it.

Yes, but if that were a real-world possibility, modifying the program
could result in an even less desirable outcome. It's only because
this is not a real concern that the OP should be messing with things
to begin with.

 

[Richard Heathfield]

Craig Franck said:

Yes, but if that were a real-world possibility,

It is. In fact, I've really seen two real-world machines really trashed
really in the real real world by undefined behaviour, on two really
separate real occasions. How real does it have to be before it's "real
world"?

modifying the program
could result in an even less desirable outcome.

Not if you modify it properly.

It's only because
this is not a real concern that the OP should be messing with things
to begin with.

You may consider it "not a real concern", but I beg to differ.

 

[santosh]

Craig Franck said:


It is. In fact, I've really seen two real-world machines really trashed
really in the real real world by undefined behaviour, on two really
separate real occasions. How real does it have to be before it's "real
world"?

Perhaps he means that it should be statistically significant?

 

[Richard Heathfield]

santosh said:

Perhaps he means that it should be statistically significant?

Perhaps he does. The problem here is in gathering the statistics. When "a
computer error" costs real people real money, there is a very
understandable tendency to just get the thing fixed ASAP and not worry too
much about the niceties of recording and publishing how precisely it went
wrong. "Was it undefined behaviour that just threw away a hundred thousand
pounds, or was it a logical error? Who cares? Just find it, fix it, and
forget it." Not a forward-thinking approach, particularly, but nevertheless
very human.

Formal academic studies are few and far between. In fact, I couldn't find
any in a cursory search just now.

So if we're content to rest in the false security of the position that "no
statistically significant link between undefined behaviour and Bad Things
Happening has ever been proved", well, okay, but don't come running to me
when your leg falls off because J Random Programmer didn't think it
important to ensure that his adding of two ints wouldn't overflow.

And yes, computer errors can and do cause deaths: cf Therac-25.

 

[Craig Franck]

Craig Franck said:

It is. In fact, I've really seen two real-world machines really trashed
really in the real real world by undefined behaviour, on two really
separate real occasions. How real does it have to be before it's "real
world"?

My point was that technical excellence and radical pessimism
aren't the same thing, and the environment must have a
reasonable degree of stability or there is a tendency to leave
well enough alone.

There is also the issue that certain non-standard practices
should be expected to work reasonably well so that they might
become common enough to make their way into the language.

 

[Richard Heathfield]

Craig Franck said:

My point was that technical excellence and radical pessimism
aren't the same thing,

True enough, but I see nothing radically pessimistic in the idea of writing
robust code according to the rules of the language. If the hardware
engineering folks were as cavalier as (many) programmers, we'd have bridges
falling down left, right and centre. Is their over-testing over-engineering
habit "radically pessimistic"? Well, perhaps it is - but it is also wise.

and the environment must have a
reasonable degree of stability or there is a tendency to leave
well enough alone.

Would you say that x86s have a "reasonable degree of stability"? I would -
and yet I've seen a couple of them trashed by undefined behaviour. And
another came very close to having its fixed disk reformatted as a result of
undefined behaviour. (If you're just learning how C strings work, "Are you
sure you want to reformat the disk? Y/N" is the sort of prompt that can
ruin your day.)

There is also the issue that certain non-standard practices
should be expected to work reasonably well so that they might
become common enough to make their way into the language.

This happened, of course, with %lf (for *printf). This was probably a Good
Thing, even though it didn't add to the expressive power of the language,
because the %lf form does at least have the merit of Least Surprise.

 

[CBFalconer]

.... snip ...

True enough, but I see nothing radically pessimistic in the idea
of writing robust code according to the rules of the language. If
the hardware engineering folks were as cavalier as (many)
programmers, we'd have bridges falling down left, right and centre.
Is their over-testing over-engineering habit "radically
pessimistic"? Well, perhaps it is - but it is also wise.

I can think of a couple of famous horrible examples. One was in
Britain about a century and a half ago, and the other was the
Tacoma Narrows circa 1940 in the USA. The opposite extreme is
exemplified by the Brooklyn Bridge in NYC, and the Victoria Bridge
in Montreal. Prince Albert opened the latter, and it is still
going strong. I have no similarly aged examples of C coding.
(but lots of failures).

 

[Richard Heathfield]

CBFalconer said:

I can think of a couple of famous horrible examples.

That's precisely my point. Failures in the engineering world do happen, yes,
but they are extraordinarily rare, compared to failures in the software
world. And that's because the engineers give a damn about Doing It Right.

<snip>

 

[Peter St. Claire]

Sorry for joining in so late. Just saw this posting.

I can vouch for your THERAC-25 (and many others). We were the consultants
on the THERAC-25 brought in by the manufacturer following the Tyler, Texas
accidents.

Peter

 

[Craig Franck]

Sorry for joining in so late. Just saw this posting.

I can vouch for your THERAC-25 (and many others). We were the consultants
on the THERAC-25 brought in by the manufacturer following the Tyler, Texas
accidents.

Thank you vetting Richard's example, but this may be a case
of generalizing the point to where he cannot be refuted.

Undefined behavior can have catastrophic consequences. But
from a risk management POV, you need to be able to weight
possible outcomes. I was objecting to a specific Reefer
Madness-like scenario.

It's also ironic that from a general systems perspective, the
worse the outcome, the more likely the ultimate defect is to be
located external to the program.

The ultimate conclusion of the THERAC-25 incident was such
behavior should have been defined:

http://en.wikipedia.org/wiki/Therac-25