Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > type safety and reinterpret_cast<>

Reply
Thread Tools

type safety and reinterpret_cast<>

 
 
Pete Becker
Guest
Posts: n/a
 
      11-01-2006
werasm wrote:
> Kai-Uwe Bux wrote:
>
>> The problem is that there is no reason to think that they would be equal,
>> either. As I pointed out in some other thread, the C++ standard does allow
>> for pointers that store more information than just a location in memory.
>> This additional information would not be used in finding the location but
>> just for defining undefined behavior in surprising ways

>
> How often does it lead to UB in practise (even though it hypothetically
> can)?
>


There is no such thing as UB in practise. Undefined behavior means only
that the language definition does not tell you what should happen.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.
 
Reply With Quote
 
 
 
 
Frederick Gotham
Guest
Posts: n/a
 
      11-01-2006
Noah Roberts:

> Correct, any use of a reinterpret_casted pointer results in undefined
> behavior. The only defined behavior is casting back and forth.


Bullshit. The behaviour of the following two snippets is defined by the C++
Standard:

Snippet (1)

unsigned i;

char unsigned *p = reinterpret_cast<char unsigned*>(&i);
char unsigned const *const pover = p + sizeof i;

do *p++ = 0; while (pover != p);


Snippet (2)

struct MyPOD { double a; int b; char *p; } obj;

double *const p = reinterpret_cast<double*>(&obj);

*p = 45.7;

>> The only case where I know of a requirement that pointer conversion
>> preserves the actual memory location is conversion to and from
>> (unsigned) char*.

>
> The problem isn't necissarily that reinterpret_cast will change the
> address of the pointer but that it won't. This becomes a major issue
> when dealing with MI.


What does MI stand for?

In the previous two snippets, the Standard necessitates that
reinterpret_cast process the pointer value correctly.

--

Frederick Gotham
 
Reply With Quote
 
 
 
 
Nate Barney
Guest
Posts: n/a
 
      11-01-2006
Frederick Gotham wrote:
> What does MI stand for?


Multiple Inheritance.

Nate
 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      11-01-2006

Frederick Gotham wrote:

> In the previous two snippets, the Standard necessitates that
> reinterpret_cast process the pointer value correctly.


You'll have to quote the standard then.

 
Reply With Quote
 
Frederick Gotham
Guest
Posts: n/a
 
      11-01-2006
Noah Roberts:

>
> Frederick Gotham wrote:
>
>> In the previous two snippets, the Standard necessitates that
>> reinterpret_cast process the pointer value correctly.

>
> You'll have to quote the standard then.



With regard to Snippet (2):

9.2.17

A pointer to a POD-struct object, suitably converted using a
reinterpret_cast, points to its initial member (or if that member is a bit-
field, then to the unit in which it resides) and vice versa. [Note: There
might therefore be unnamed padding within a POD-struct object, but not at its
beginning, as necessary to achieve appropriate alignment. ]

I'll post the quote relevant to Snippet (1) when I get the chance... although
you should note that we can treat any object as if it were an array of
unsigned char's, and we can only do that by converting pointers (or by
casting to a reference which is equivalent).

--

Frederick Gotham
 
Reply With Quote
 
werasm
Guest
Posts: n/a
 
      11-02-2006

Pete Becker wrote:
> werasm wrote:
> > Kai-Uwe Bux wrote:
> >
> >> The problem is that there is no reason to think that they would be equal,
> >> either. As I pointed out in some other thread, the C++ standard does allow
> >> for pointers that store more information than just a location in memory.
> >> This additional information would not be used in finding the location but
> >> just for defining undefined behavior in surprising ways

> >
> > How often does it lead to UB in practise (even though it hypothetically
> > can)?
> >

>
> There is no such thing as UB in practise. Undefined behavior means only
> that the language definition does not tell you what should happen.


Ok, rephrase: How often does it lead to unwanted behaviour in practise,
given the specific example?

Regards,

Werner

 
Reply With Quote
 
Gianni Mariani
Guest
Posts: n/a
 
      11-02-2006
werasm wrote:
> Pete Becker wrote:

....
>> There is no such thing as UB in practise. Undefined behavior means only
>> that the language definition does not tell you what should happen.

>
> Ok, rephrase: How often does it lead to unwanted behaviour in practise,
> given the specific example?


This is where the scientist and the engineer diverge.

There are many cases where it would not happen with the current
compilers and if in some wild future the compiler behaves differently,
in all likeliness the code would fail to run at all (SEGV and such) then
it's safe to use the compiler specific behaviour.

One case where it is not safe is things like:

int x = ..
int y = ..

return x << y; // if y is larger than the number of bits in an int it is UB

In this case some systems will return x and some will return 0. This
can lead to subtle errors that could one day trigger something very
undesirable giving little warning of the lurking failure mode.

On the other hand ...


char x[5];

int y = * reinterpret_cast< int * >( x + 1 );

will fail with a SIGBUS on systems that don't allow unaligned access.
You have plenty of warning in the form of the OS telling you to get
stuffed, in this case UB is well defined. Yes, theoretically, some new
platform can do something strange but in all likelihood that will not
happen for a number of reasons.

So the real response to Pete's question is :

"What is the current set of manifestations of UB for this example in
todays 4 most common compilers ?"

If the answer comes back, they all do the same thing, then you can
pretty much say it's a defacto standard and that any future compiler
will probably behave the same way.

At the then of the day, popular compilers have a very large intersection
in their problem space so it's safe to bet they more likely than not
will take the same UB design choices.
 
Reply With Quote
 
Richard Herring
Guest
Posts: n/a
 
      11-08-2006
In message
<4549ff30$0$8042$(E-Mail Removed)>, Gianni
Mariani <(E-Mail Removed)> writes
>werasm wrote:
>> Pete Becker wrote:

>...
>>> There is no such thing as UB in practise. Undefined behavior means only
>>> that the language definition does not tell you what should happen.

>> Ok, rephrase: How often does it lead to unwanted behaviour in
>>practise,
>> given the specific example?

>
>This is where the scientist and the engineer diverge.
>
>There are many cases where it would not happen with the current
>compilers and if in some wild future the compiler behaves differently,
>in all likeliness the code would fail to run at all (SEGV and such)
>then it's safe to use the compiler specific behaviour.
>
>One case where it is not safe is things like:
>
>int x = ..
>int y = ..
>
>return x << y; // if y is larger than


-- or equal to! ---

>the number of bits in an int it is UB


I wonder how many people that one has caught out?

<raises hand ;->

--
Richard Herring
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Implementing Interfaces and Type Safety (OOP Newbie in Perl) Veli-Pekka Tštilš Perl Misc 7 08-20-2005 10:02 AM
Enumerators, Templates, and Type Safety Matt Taylor C++ 6 07-13-2004 01:16 PM
newbie question on "Type Safety" Raymond Du ASP .Net 1 06-21-2004 11:42 AM
type safety in java 1.5 (bug or hole?) York Werres Java 24 05-25-2004 06:05 PM
Runtime type-safety (for linked lists) Dave C Programming 2 09-29-2003 09:42 AM



Advertisments