Invalid cast

[Frederic Mayot]

Hi,
Can someone give me an explanation why the following code produces a
bug. I think it's related to the compiler and that the first line is
not OK. I have no pb with gcc 3.4 but the bug appeared with gcc 4.1.1
A* p = ...;
int l;
(char*&)p += l;
The right way is
p = reinterpret_cast<A*>(reinterpret_cast<char*>(p) + l);
Thanks
Fred

[Alf P. Steinbach]

* Frederic Mayot:

Hi,
Can someone give me an explanation why the following code produces a
bug. I think it's related to the compiler and that the first line is
not OK. I have no pb with gcc 3.4 but the bug appeared with gcc 4.1.1
A* p = ...;
int l;
(char*&)p += l;
The right way is
p = reinterpret_cast<A*>(reinterpret_cast<char*>(p) + l);

reinterpret_cast, or a C-style cast that resolves to reinterpret_cast,
is a sure way to introduce a bug.

Remove the casts (you'll probably have to fix other code) and chances
are you're removing the bug too.

Hope this helps.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[JLS]

On Feb 6, 11:56 am, "Alf P. Steinbach" <[e-mail]:

* Frederic Mayot:

Hi,
Can someone give me an explanation why the following code produces a
bug. I think it's related to the compiler and that the first line is
not OK. I have no pb with gcc 3.4 but the bug appeared with gcc 4.1.1
A* p = ...;
int l;
(char*&)p += l;
The right way is
p = reinterpret_cast<A*>(reinterpret_cast<char*>(p) + l);

reinterpret_cast, or a C-style cast that resolves to reinterpret_cast,
is a sure way to introduce a bug.

Remove the casts (you'll probably have to fix other code) and chances
are you're removing the bug too.

Hope this helps.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

There is other strangeness here also.

We don't know if p is properly allocated, since that code wasn't
provided.
the variable l is not initialized, so the line p += l is going to do
something unexpected.

I don't believe that "the code produces a bug" or "the bug appeared
with gcc 4.1.1" are proper ways of phrasing it. "The code is buggy",
or "the bug was first noticed with gcc 4.1.1" would be more accurate.
Code cannot produce a bug. The bug is in the code itself, not a
product of the code.

[Frederic Mayot]

Thanks a lot for correcting my English. Next time, I will explicitly
ask for a technical answer ;-)

In the code I gave, the memory area between p and (char*)p + l is
valid. Let's suppose that we have
char* c = new char[M]; // M l
A* p = reinterpret_cast<A*>(c);

I also forgot to tell that this kind of code is used in an allocator.
So please don't tell me that reinterpret_casts are not appropriate in
that case.

I just wondered why
(char*&)p += l;
could be differently compiled than
p = reinterpret_cast<A*>(reinterpret_cast<char*>(p) + l);

If you don't know, kindly avoid answers like "this is not defined in
the C++ standard"

(My message was also posted to gnu.gcc.help and gnu.g++.help)

[Alf P. Steinbach]

* Frederic Mayot:

>
I just wondered why
(char*&)p += l;
could be differently compiled than
p = reinterpret_cast<A*>(reinterpret_cast<char*>(p) + l);

In the first case you're reinterpreting a reference to the pointer p.

In the second case you're reinterpreting pointer p's value.

Reinterpreting a value need not preserve the bitpattern, although a
preserved bitpattern (except for padding with zeroes) is somewhat
implicit in the word "reinterpret".

To be sure you have working code you need to hold the pointer value in a
char* or void* (or variations of char): other data pointer types may not
be sufficient to hold an arbitrary pointer value.

So, first copy the pointer value to char*, then increment (which is what
the second statement does, in practice).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Andrey Tarasevich]

Frederic Mayot wrote:

...
I just wondered why
(char*&)p += l;
could be differently compiled than
p = reinterpret_cast<A*>(reinterpret_cast<char*>(p) + l);
...

Let's just take a different example first. Let's assume we are using a platform
with sizeof(float) == sizeof(int) and identical alignment requirements for both
types. Consider the following code

float f = 5.0;
int i1 = (int) f; // 1
int i2 = *(int*) &f; // 2

Take a close look at lines labeled 1 and 2. Both lines will be accepted by the
compiler (there are issues here from the very pedantic point of view, but let's
just assume that the compiler accepted both). But do you understand the
difference between the two?

In the line 1 we have a cast that converts a 'float' into an 'int'. The behavior
of this conversion is defined by the language. Variable 'i1' will be initialized
with value '5' and that does not depend on the implementation.

In the line 2 we are actually create a pointer of type 'float*' that points to
'f', forcefully convert it to type 'int*' (this is implementation-defined, but
let's assume that it still points to the same spot) and then dereference it as
if we have an 'int' object in memory occupied by 'f'. In other words, in this
case we just take the raw memory occupied by 'float f' and read it as an 'int'
object. What do you think the result of this is going to be? The truth is,
there's absolutely no way to predict it from the language point of view. The
physical representation of 'float' value '5.0' will normally have no relation to
the physical representation of 'int' value '5', so there's virtually no chance
that 'i2' will be initialized with '5'. In practice, if it doesn't crash, you
will see some what looks like garbage in 'i2'.

I'm saying all this in order to emphasize the difference between _converting_ an
object of one type to another type (which is what we have in the first case),
and _reinterpreting_ the raw memory occupied by an object of one type as an
object of another type (which is what we have in the second case). The former
makes perfect sense when defined by the language or implementation, while an
attempt to do the latter makes no sense at all in majority of cases.

Now, back to your code.

Expression '(char*&) p' is equivalent to '*(char*) &p', which attempts to do
pretty much the same thing as line 2 in my float-int example. It is nothing else
that an attempt to _reinterpret_ the memory occupied by 'p' as an object of type
'char*'. Object 'p' has type 'A*'. Physical representation of 'A*' has
absolutely no relation to the physical representation of 'char*'. Which means
that this reinterpretation attempt makes no sense for the very same reason line
2 in the my float-int example made no sense.

Expression 'p = (A*) ((char*) p + 1)' (rewritten for brevity) is something
completely different. It is similar to the line 1 in the my float-int example.
It actually converts an 'A*' value into an 'char*' value, performs the increment
and then converts it back to 'A*' type. These conversions are
implementation-defined but, assuming that your implementation defines them the
way you want it to, they produce meaningful results.

--
Best regards,
Andrey Tarasevich

[Frederic Mayot]

Physical representation of 'A*' has absolutely no relation to the
physical representation of 'char*'

You mean that A* can be represented as a 64bits integer in little
endian and char* as a 32bits integer in big endian, for example?
Do you have an example of a compiler which would use different
representations for pointers???
What I don't understand is that some conversions will be needed in the
assembler code so that all pointers (addresses) would be represented
in the system specific representation. Is that right?

[Frederic Mayot]

I tried to compile two codes with gcc/64bits -O2. I'm not sure my
example makes sense...

1) First snipped code
%%%%%%%%%%%%%%%%%%%%%%%%%%%%
struct A {double c[4];};
A* p = reinterpret_cast<A*>(new char[sizeof(A)*2]);
(char*&)p += sizeof(A);
p->c[2] = 12.0;

main:
..LFB2:
subq $24, %rsp
..LCFI0:
movl $64, %edi
call _Znam
movabsq $4622945017495814144, %rdx
movq %rdx, 16(%rax)
xorl %eax, %eax
addq $24, %rsp
ret
%%%%%%%%%%%%%%%%%%%%%%%%%%%%

2) Second one
%%%%%%%%%%%%%%%%%%%%%%%%%%%%
struct A {double c[4];};
A* p = reinterpret_cast<A*>(new char[sizeof(A)*2]);
p = reinterpret_cast<A*>(reinterpret_cast<char*>(p) + sizeof(A));
p->c[2] = 12.0;

main:
..LFB2:
subq $8, %rsp
..LCFI0:
movl $64, %edi
call _Znam
movabsq $4622945017495814144, %rdx
movq %rdx, 48(%rax)
xorl %eax, %eax
addq $8, %rsp
ret
%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Here is the difference:
movq %rdx, 16(%rax) // with (char*&)p += sizeof(A);
movq %rdx, 48(%rax) // with
reinterpret_cast<A*>(reinterpret_cast<char*>(p) + sizeof(A));

The second assembler code is what I expect. Not the first.

[JLS]

On Feb 6, 1:38 pm, "Frederic Mayot" <[e-mail]:

Thanks a lot for correcting my English. Next time, I will explicitly
ask for a technical answer ;-)

In the code I gave, the memory area between p and (char*)p + l is
valid. Let's suppose that we have
char* c = new char[M]; // M l
A* p = reinterpret_cast<A*>(c);

I also forgot to tell that this kind of code is used in an allocator.
So please don't tell me that reinterpret_casts are not appropriate in
that case.

I just wondered why
(char*&)p += l;
could be differently compiled than
p = reinterpret_cast<A*>(reinterpret_cast<char*>(p) + l);

If you don't know, kindly avoid answers like "this is not defined in
the C++ standard"

(My message was also posted to gnu.gcc.help and gnu.g++.help)

in the code you gave, "l" is an integer that is not initialized.
Sometimes it will have the value 0. Sometimes, 30,000. It is hard for
me to believe that you could know for a fact that "the memory area
between p and (char*)p + l is valid" for all possible values of "l".

My goal wasn't to correct your English, but I've run across a lot of
people who would phrase things the way you did, not because their
English was bad, but because their English betrayed a hidden bias that
the problem wasn't because of something buggy in their code, it was
the fault of the compiler or the language or an act of God.

As far as why the cast behaves differently, I find both examples
sufficiently obfuscating that my mind refuses to process the
information. I guess if I had to debug code like that, I would sit
down and figure out what the compiler was doing, but I would probably
rewrite the code so that it was understandable at the same time.

I'm not 100 percent sure why you expect the compiler to operate the
same. Without spending much thought on it, I would expect that

(char*)p += l;

to be roughly the same as
reinterpret_cast<char*>(p) + l

but you have that pesky little "&" in there.

[Andrey Tarasevich]

Frederic Mayot wrote:

Physical representation of 'A*' has absolutely no relation to the
physical representation of 'char*'

You mean that A* can be represented as a 64bits integer in little
endian and char* as a 32bits integer in big endian, for example?

In theory - yes. The language specification imposes certain restrictions on
pointer representations, that require, for example, that 'char*' and 'void*'
pointers use identical representations. But in case of 'char*' and some 'A*'
(assuming that 'A' is neither 'char' nor 'void') there's no such requirement.

Do you have an example of a compiler which would use different
representations for pointers???

I don't know of any. Admittedly, this would be a rather exotic implementation.

In practice the code you used (meaning that '(char*&) p += 1' part) will work
"as expected" in many (or most) cases. This, BTW, brings the question: what is
it exactly that you referred to as a "bug" in your original message? What
exactly is the problem you had with '(char*&) p += 1'?

What I don't understand is that some conversions will be needed in the
assembler code so that all pointers (addresses) would be represented
in the system specific representation. Is that right?

Well, yes. With a few "but"s.

Firstly, in practice, when it comes to "plain" pointer types like 'int*',
'char*' or 'A*' it wouldn't make much sense for an implementation to blindly
insist on a representation that is significantly different from the
hardware-specific one. Normally, you won't see any conversions in the machine
code, simply becuase they are not necessary.

Secondly, still the representation might be different from the hardware-specific
one, assuming that the conversion you mention are simple or trivial. In fact,
many platforms are actually using such representations, even though it might not
be too noticeable at the first sight. For example, the current x86 platform is
based on segmented memory access model and its full hardware pointer is
represented by a 'selector:offset' pair. But most C++ implementations in that
platform stick to one-segment flat-memory model, meaning that just the 'offset'
pair is used as C++ pointer. Of course, this does not require any repetitive
"conversion" efforts from the compiler.

Thirdly, speaking of C++ pointers in general, some kinds of C++ pointers have no
hardware-specific counterparts, meaning that one should normally expect that
they will be represented as somethig not directly related to underlying
hardware. Take pointers-to-members for example. But that's a different story.

--
Best regards,
Andrey Tarasevich