Undefined behaviour

[marbac]

Hi,

i heard a lot about "undefined behaviour" in this and other newsgroups
dealing with c/c++.

Is there a list where all cases with undefined behaviour in C++ are listed?

regards marbac

[Ioannis Vranos]

Rolf Magnus wrote:

If an implementation of vector's operator[]() threw an out_of_range
exception or anything else, it would be a system-specific extension,

It would be an instance of undefined behaviour, just like a crash would
be. Still you would probably not call a crash a "system-specific
extension".

The system-specific extension I was talking about above, was the fact of
throwing an exception.


Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

[Duane Hebert]

"Ron Natalie" <ro*@sensor.com > wrote in message news:40******** *************** @news.newshosti ng.com...

"Default User" <fi********@boe ing.com.invalid > wrote in message news:40******** ******@boeing.c om.invalid...

Rolf Magnus wrote:

4) Writing to a member of a union and then reading another one

This is implementation-defined in C. I'd be surprised if it was
different in C++.

C says it's unspecified, there is no need for the implementation to have a specific
behavior. In the general case, it's undefined behavior for C++ (there are some
specific outs).

I've heard this before but you mean basically that:

union spoo {
unsigned char c[sizeof(short)];
short s;
};

spoo doh;
doh.c[0] = LOW_BYTE;
doh.c[1] = HIGH_BYTE;

cout << doh.s ;
is undefined?
This is a common method to interpret unsigned char
data from I/O devices. I know it can be done without
a union but not as cleanly. I don't see how this could
not work (as long as you are aware of the endianness
of the unsigned chars etc.)

Any thoughts? At any rate, what would be the purpose
of a union?

[Ioannis Vranos]

Duane Hebert wrote:

"Ron Natalie" <ro*@sensor.com > wrote in message news:40******** *************** @news.newshosti ng.com...
I've heard this before but you mean basically that:

union spoo {
unsigned char c[sizeof(short)];
short s;
};

spoo doh;
doh.c[0] = LOW_BYTE;
doh.c[1] = HIGH_BYTE;

cout << doh.s ;
is undefined?
This is a common method to interpret unsigned char
data from I/O devices. I know it can be done without
a union but not as cleanly. I don't see how this could
not work (as long as you are aware of the endianness
of the unsigned chars etc.)

Any thoughts? At any rate, what would be the purpose
of a union?

Strictly speaking reading doh.s which was not properly assigned a value
is undefined behaviour.
Well union comes from C, and systems in the past had very severe space
constraints, so for example you could use a union in half a program as
an integer and then as a float. :-)


Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

[Duane Hebert]

"Ioannis Vranos" <iv*@guesswh.at .grad.com> wrote in message news:cd******** ***@ulysses.noc .ntua.gr...

Strictly speaking reading doh.s which was not properly assigned a value
is undefined behaviour.
But the union shares the memory between the unsigned char[2] and the
short. The unsigned char was assigned a value, reading the short
after is just interpreting the same memory as a short no?

Well union comes from C, and systems in the past had very severe space
constraints, so for example you could use a union in half a program as
an integer and then as a float. :-)

True. It's been a while though ...

[Rolf Magnus]

Duane Hebert wrote:

I've heard this before but you mean basically that:

union spoo {
unsigned char c[sizeof(short)];
short s;
};

spoo doh;
doh.c[0] = LOW_BYTE;
doh.c[1] = HIGH_BYTE;

cout << doh.s ;
is undefined?
This is a common method to interpret unsigned char
data from I/O devices.

It might be common, but it is abuse of unions. They were never meant for
such a thing, even if it works on many platforms. The way to do this is
reniterpret_cas t.

[Peter Koch Larsen]

"Ioannis Vranos" <iv*@guesswh.at .grad.com> skrev i en meddelelse
news:cd******** ***@ulysses.noc .ntua.gr...

Peter Koch Larsen wrote:

You're right of course. My point was that vector::operato r[] is allowed to verify the range. The assert is an excellent solution.
If an implementation of vector's operator[]() threw an out_of_range
exception or anything else, it would be a system-specific extension, and
code assuming that this operator is index-checked, cannot be considered
portable.

No it would not. Elsewhere in this thread you have quoted the standard on
undefined behaviour - read it and tell me if you find an assert or a throw
kochs_exception would violate the standard.

/Peter
Furthermore, since at() is provided for this, operator[] is reasonable
to be defined having an efficient access to the data.


Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

[Rolf Magnus]

Peter Koch Larsen wrote:

"Ioannis Vranos" <iv*@guesswh.at .grad.com> skrev i en meddelelse
news:cd******** ***@ulysses.noc .ntua.gr...

Peter Koch Larsen wrote:

> You're right of course. My point was that vector::operato r[] is
> allowed to > verify the range. The assert is an excellent solution.

If an implementation of vector's operator[]() threw an out_of_range
exception or anything else, it would be a system-specific extension,
and code assuming that this operator is index-checked, cannot be
considered portable.

No it would not. Elsewhere in this thread you have quoted the standard
on undefined behaviour - read it and tell me if you find an assert or
a throw kochs_exception would violate the standard.

I agree that I wouldn't call it a system-specific extension. Throwing an
exception is just as much of a system specific extension as crashing
and output like "segmentati on fault, core dumped" or just ignoring the
faulty access.
But he's right in that depending on an exception being thrown is
non-portable. Depending on any specific behaviour when doing something
that - according to the standard - invokes undefined behaviour is
non-portable.

[Peter Koch Larsen]

"Rolf Magnus" <ra******@t-online.de> skrev i en meddelelse
news:cd******** *****@news.t-online.com...

Peter Koch Larsen wrote:

"Ioannis Vranos" <iv*@guesswh.at .grad.com> skrev i en meddelelse
news:cd******** ***@ulysses.noc .ntua.gr...

Peter Koch Larsen wrote:

> You're right of course. My point was that vector::operato r[] is
> allowed

to

> verify the range. The assert is an excellent solution.

If an implementation of vector's operator[]() threw an out_of_range
exception or anything else, it would be a system-specific extension,
and code assuming that this operator is index-checked, cannot be
considered portable.

No it would not. Elsewhere in this thread you have quoted the standard
on undefined behaviour - read it and tell me if you find an assert or
a throw kochs_exception would violate the standard.

I agree that I wouldn't call it a system-specific extension. Throwing an
exception is just as much of a system specific extension as crashing
and output like "segmentati on fault, core dumped" or just ignoring the
faulty access.
But he's right in that depending on an exception being thrown is
non-portable. Depending on any specific behaviour when doing something
that - according to the standard - invokes undefined behaviour is
non-portable.

I fully agree. This is not something you can rely on, but it can be handy
while developing your application. Debug it on a platform that checks for
invalid accesses and it helps you a little before deplying your platform on
your final target.

/Peter

[Default User]

Duane Hebert wrote:

"Ron Natalie" <ro*@sensor.com > wrote in message news:40******** *************** @news.newshosti ng.com...

C says it's unspecified, there is no need for the implementation to have a specific
behavior. In the general case, it's undefined behavior for C++ (there are some
specific outs).

I've heard this before but you mean basically that:

Well, Ron said that but he was incorrect. I already quoted the C
standard on the issue. It's implementation-defined, not unspecified.
That means that an implementation has to select a behavior and document
it.

Brian Rodenborn

[Default User]

Duane Hebert wrote:

"Ron Natalie" <ro*@sensor.com > wrote in message news:40******** *************** @news.newshosti ng.com...

C says it's unspecified, there is no need for the implementation to have a specific
behavior. In the general case, it's undefined behavior for C++ (there are some
specific outs).

I've heard this before but you mean basically that:

Well, I think what Ron said was somewhat confusing. I already quoted the
C standard on the issue. It's implementation-defined, that means that
the standard doesn't impose any behavior, but the implementation has to
select a behavior and document it. So the behavior for a user is not
unspecified, you can check your documentation.

There's also the bit about the union members being structs with common
initial sequences.

union spoo {
unsigned char c[sizeof(short)];
short s;
};

spoo doh;
doh.c[0] = LOW_BYTE;
doh.c[1] = HIGH_BYTE;

cout << doh.s ;

is undefined?
Not in C. Some have said that is so in C++, but I haven't seen a quote
from the standard. Usually these things are the same between the
languages, but sometimes not. Obviously, the fact that all data is POD
in C but not in C++ may well be a factor.
This is a common method to interpret unsigned char
data from I/O devices. I know it can be done without
a union but not as cleanly. I don't see how this could
not work (as long as you are aware of the endianness
of the unsigned chars etc.)
It likely would. That doesn't mean it's guaranteed. You can do the same
thing by casting a pointer to the object to a pointer to unsigned char,
then access the bytes that way. That is standard.
Any thoughts? At any rate, what would be the purpose
of a union?

These days, very little. I haven't used a union in anger since the DOS
days.

Brian Rodenborn


Brian Rodenborn