Unintialized Pointer

[siddhu]

Dear Experts,

In the following Program

class A
{
public:
void print()
{
cout<<"Hello World"<<endl;
}
};

int main()
{
A *a;
(*a).print();
}

If we declare a class pointer which is uninitialized and we try to
call a member function (which is not accessing any data member of the
class) it works fine. Why?
Does standard allow this?

Regards,
Siddharth

 

[red floyd]

Dear Experts,

In the following Program

class A
{
public:
void print()
{
cout<<"Hello World"<<endl;
}
};

int main()
{
A *a;
(*a).print();
}

If we declare a class pointer which is uninitialized and we try to
call a member function (which is not accessing any data member of the
class) it works fine. Why?
Does standard allow this?

The standard says that such behavior is undefined. Undefined behavior
can do anything, including but not limited to:

* working "as expected"
* core dumping
* reformatting your hard drive
* calling NORAD and starting World War III
* Murdering the crew and locking the pod bay doors.

Note that working "as expected" is one of the options, since it is part
of "anything".

 

[Juha Nieminen]

The standard says that such behavior is undefined. Undefined behavior
can do anything, including but not limited to:

* working "as expected"
* core dumping
* reformatting your hard drive
* calling NORAD and starting World War III
* Murdering the crew and locking the pod bay doors.

I have never understood why it's such a common "joke" to say that
"undefined behavior" means <insert physically impossible and completely
wacky thing here>.

Sure, the letter of the expression "undefined behaviour" might "allow"
the compiler to do *anything*. However, I think that the spirit of that
expression simply means "the effects can be random because the values
cannot be guaranteed". In the specific context of trying to read an
uninitialized variable it means that the variable could have any value,
and no specific value is specified by the standard. It certainly does
not mean that trying to read an uninitialized variable will "call
NORAD and start WW3".

Why can't people just tell what may happen *in practice* instead of
coming up with all the tired overly-repeated jokes?

 

[Default User]

siddhu wrote:

If we declare a class pointer which is uninitialized and we try to
call a member function (which is not accessing any data member of the
class) it works fine. Why?
Does standard allow this?

There is no defined behavior for Undefined Behavior.




Brian

 

[Juha Nieminen]

If we declare a class pointer which is uninitialized and we try to
call a member function (which is not accessing any data member of the
class) it works fine. Why?
Does standard allow this?

It can actually be proven mathematically that it's impossible for
a program to determine, in the general case, if a certain piece of
code is called or not. Assume this:

int i;
if(someFunction()) i = 5;
use(i);

It might be that someFunction() always returns true and thus there's
no problem in the above code, but in the general case there exists no
algorithm to determine that. There can't exist such an algorithm. This
problem is related to http://en.wikipedia.org/wiki/Halting_problem

The only thing the compiler can do is to warn that the variable
*might* be used uninitialized, and if in your case it doesn't, then
you should turn a higher level of warnings on (or use a better
compiler).

 

[Default User]

Juha Nieminen wrote:

I have never understood why it's such a common "joke" to say that
"undefined behavior" means <insert physically impossible and
completely wacky thing here>.

Sure, the letter of the expression "undefined behaviour" might
"allow" the compiler to do anything. However, I think that the spirit
of that expression simply means "the effects can be random because
the values cannot be guaranteed".

Nonsense. The effects need not be random at all. They may be pretty
consistent, which is how many worms and viruses work.

In the specific context of trying
to read an uninitialized variable it means that the variable could
have any value, and no specific value is specified by the standard.

Which means, as it's pointer, where it accessing is not specified.

It certainly does not mean that trying to read an uninitialized
variable will "call NORAD and start WW3".

In fact, Very Bad Things have happened through undefined behavior.



Brian

 

[red floyd]

I have never understood why it's such a common "joke" to say that
"undefined behavior" means <insert physically impossible and completely
wacky thing here>.

Are you implying that HAL 9000's actions in the film 2001 aren't a
result of UB? Seems to me that's exactly what happened....

 

[red floyd]

I have never understood why it's such a common "joke" to say that
"undefined behavior" means <insert physically impossible and completely
wacky thing here>.

> [redacted]

Why can't people just tell what may happen *in practice* instead of
coming up with all the tired overly-repeated jokes?

Note that I left off some of the more improbable ones such as "causing
monkeys to fly out of my butt".

 

[Howard]

It can actually be proven mathematically that it's impossible for
a program to determine, in the general case, if a certain piece of
code is called or not. Assume this:

int i;
if(someFunction()) i = 5;
use(i);

It might be that someFunction() always returns true and thus there's
no problem in the above code, but in the general case there exists no
algorithm to determine that. There can't exist such an algorithm. This
problem is related to http://en.wikipedia.org/wiki/Halting_problem

The only thing the compiler can do is to warn that the variable
*might* be used uninitialized, and if in your case it doesn't, then
you should turn a higher level of warnings on (or use a better
compiler).

The question was if the Standard allowed the code to work properly when
using an uninitialized pointer to a class. (And when he said it "works
fine", I assume he meant it runs without crashing or other detectable bad
behavior.)

According to the Standard, dereferencing an uninitialized pointer is
undefined behavior. It might work, it might not. The Standard doesn't
specify how it should behave.

As to whether the compiler could warn you that the specific code shown was a
problem, it's certainly possible. It may not be possible to always know (at
compile time) whether a pointer will be initialized or not when it is
eventually used, but the specific code shown certainly "could* be detected
as a problem by a compiler. (But that wasn't the OP's question.)

-Howard

 

[Howard]

The standard says that such behavior is undefined. Undefined behavior
can do anything, including but not limited to:

* working "as expected"
* core dumping
* reformatting your hard drive
* calling NORAD and starting World War III
* Murdering the crew and locking the pod bay doors.

I have never understood why it's such a common "joke" to say that
"undefined behavior" means <insert physically impossible and completely
wacky thing here>.

[redacted]

Why can't people just tell what may happen *in practice* instead of
coming up with all the tired overly-repeated jokes?

Note that I left off some of the more improbable ones such as "causing
monkeys to fly out of my butt".

If I recall correctly - and I don't - the Standards Committee discussed
restricting "undefined behavior" to explicitly exclude that particularly
nasty behavior. The proposal was shot down when it was pointed out that
"someone might write code to *intentionally* cause monkeys to fly out of red
floyd's butt... and then what if THAT code exhibited undefined behavior?!?"

(Plus it wouldn't really be "undefined behavior" if said behavior were
excluded, eh?)

-Howard

 

[red floyd]

The proposal was shot down when it was pointed out that
"someone might write code to *intentionally* cause monkeys to fly out of red
floyd's butt... and then what if THAT code exhibited undefined behavior?!?"

So they discussed *my* butt in the Standards Committee? I'm not sure
whether to be flattered, scared, or disturbed!

Thanks for the laugh, Howard!

 

[Jim Langston]

I have never understood why it's such a common "joke" to say that
"undefined behavior" means <insert physically impossible and completely
wacky thing here>.

Sure, the letter of the expression "undefined behaviour" might "allow"
the compiler to do *anything*. However, I think that the spirit of that
expression simply means "the effects can be random because the values
cannot be guaranteed". In the specific context of trying to read an
uninitialized variable it means that the variable could have any value,
and no specific value is specified by the standard. It certainly does
not mean that trying to read an uninitialized variable will "call
NORAD and start WW3".

Why can't people just tell what may happen *in practice* instead of
coming up with all the tired overly-repeated jokes?

Right, unless you're working on the whitehouse phone system programming that
the president uses. And some undefined behavior calls the wrong number...

 

[Bo Persson]

Juha Nieminen wrote:
:: red floyd wrote:
::: The standard says that such behavior is undefined. Undefined
::: behavior can do anything, including but not limited to:
:::
::: * working "as expected"
::: * core dumping
::: * reformatting your hard drive
::: * calling NORAD and starting World War III
::: * Murdering the crew and locking the pod bay doors.
::
:: I have never understood why it's such a common "joke" to say that
:: "undefined behavior" means <insert physically impossible and
:: completely wacky thing here>.
::
:: Sure, the letter of the expression "undefined behaviour" might
:: "allow" the compiler to do *anything*. However, I think that the
:: spirit of that expression simply means "the effects can be random
:: because the values cannot be guaranteed".

That's the case for "unspecified behaviour". A certain number of
outcomes are possible, we just cannot generally tell which one.

:: In the specific context
:: of trying to read an uninitialized variable it means that the
:: variable could have any value, and no specific value is specified
:: by the standard. It certainly does not mean that trying to read an
:: uninitialized variable will "call NORAD and start WW3".

It is not at all physically impossible!

Let's assume that the OP programs a radar computer in an early warning
system. The computer contains a modem with memory mapped ports. To
make sure that the operators will not use the modem to download
"pr0n", the number to call is hardwired to NORAD red-alert.

Now, accessing one specific port of the modem triggers the actual
call. It doesn't matter if it is a read or a write access, it is the
actual address that is the trigger.

Let's try this out with a random uninitialized pointer...

:: Why can't people just tell what may happen *in practice* instead
:: of coming up with all the tired overly-repeated jokes?

In practice it just works anyway, sometimes.


Bo Persson

 

[Andre Kostur]

I have never understood why it's such a common "joke" to say that
"undefined behavior" means <insert physically impossible and completely
wacky thing here>.

It's a fun way to illustrate that you should not invoke Undefined
Behaviour. I prefer to use the example of "Invoking UB may format your
hard drive.". But same idea.

Sure, the letter of the expression "undefined behaviour" might "allow"
the compiler to do *anything*. However, I think that the spirit of that
expression simply means "the effects can be random because the values
cannot be guaranteed". In the specific context of trying to read an
uninitialized variable it means that the variable could have any value,
and no specific value is specified by the standard. It certainly does
not mean that trying to read an uninitialized variable will "call
NORAD and start WW3".

Why can't people just tell what may happen *in practice* instead of
coming up with all the tired overly-repeated jokes?

Because if someone were told what may happen in practice, they'd the just
turn around and do the Undefined Behaviour anyway, becasue "in practice"
nothing goes wrong. Until you port the code somewhere where it does go
wrong. Then either that programmer, or whomever is now porting the code,
complains about why doesn't such-and-such work. It works on Windows (or
Linux, or wherever they originally wrote the code), why not here?

Undefined Behaviour is Undefined Behaviour. There is no "what may happen
in practice". Anything can happen. Anything ranging from "working
properly" to crashing to "format your HD" (crashing with style?) to
"avian simians emerging from somewhere" (if the compiler implementor is
sufficiently demented....) to causing your CRT to explode (not that
unreasonable... older video cards and such didn't have controls on their
frequencies, so they could overdrive the electron gun in the CRT causing
it to overheat and explode.... so doing something like setFrequency
(newFreq) where newFreq is an uninitialized variable (reading from an
uninitialized variable is Undefined Behaviour), could set the frequency
too high and break your CRT).

 

[James Kanze]

I have never understood why it's such a common "joke" to say that
"undefined behavior" means <insert physically impossible and completely
wacky thing here>.

Because it highlights the fact that no list of possible
behaviors can be exhaustive.

Sure, the letter of the expression "undefined behaviour" might "allow"
the compiler to do *anything*. However, I think that the spirit of that
expression simply means "the effects can be random because the values
cannot be guaranteed". In the specific context of trying to read an
uninitialized variable it means that the variable could have any value,
and no specific value is specified by the standard.

Or that it could cause a hardware trap. As long as you're just
reading, those are probably the only possible behaviors (but I'm
not 100% sure about it).

It certainly does
not mean that trying to read an uninitialized variable will "call
NORAD and start WW3".

Why can't people just tell what may happen *in practice* instead of
coming up with all the tired overly-repeated jokes?

Well, I've seen dereferencing an uninitialized pointer hang the
machine, so that you had to power it off and then on again to do
anything with the machine. And I've seen writing through an
uninitialized pointer actually cause the next call to open to
render the disk unreadable, so that it required reformatting.
And I've worked on a system where an incorrect memory write
could cause the system to telephone your boss.

One of the reasons why C and C++ stress "undefined behavior" so
much is because they are used on such a wide variety of systems.
*IF* you're running application level software on a typical
workstation or (modern) PC, then about the worse thing that can
happen is a core dump (or whatever they call it under Windows),
but C/C++ are designed for a lot of other environments as well.
And a core dump can have serious secondary effects as well.
I've worked on systems where we had contractual penalties for
down time, and the time between a core dump and the time the
program was back up and running would cost us over 10000 Euros.
(But that's a secondary effect---a classical secondary effect of
buffer overflow, for example, is to allow unknown persons to
execute arbitrary code in priviledged mode on your machine.)