Re: Does this memory access yield undefined behaviour?
On Apr 1, 12:17 am, "Matthias Hofmann" <hofm...@anvil-soft.com> wrote:
Hello everyone,
please have a look at the following code, which is a stripped-down version
of a 24 bit graphics routine I am working at:
[snip]
Now I wonder whether my code yields undefined behaviour?
Let's see.
1- I think the standard says that you can cast from T* to void* and
back to T* and have that work for all types T. (This may also work for
char*. Does it? See C++03 3.9.2.4. It says that char* and void* shall
have the same representation and alignment constraints. Odd that
unsigned char* isn't mentioned here.) This doesn't work for T* to U*
and back to T* for all types T and U, specifically int*. This is
undefined behavior.
2- Alignment issues. reinterpret_cast<int*>(reinterpret_cast<char*>
(pi) + 3) may not be a valid int pointer. This is undefined behavior.
(Do note that new char[] and new unsigned char[] return memory which
is aligned for any type (assuming the allocation size is large enough
to hold the object), see C++ 5.3.4.10.)
3- You access 1 byte off the end of the array. This is undefined
behavior.
4- You access memory of the char array through an int pointer. Aka the
strict aliasing rule. See C++03 3.10.15. This is undefined behavior.
memcpy (?? and the other related cstdlib functions ??), union, and
placement new are options to get around this.
5- Endian issues with the bit twiddling. You might not get the results
you want. Implementation defined.
6- Assuming specific size of int. Implementation defined.
On Apr 1, 3:08 pm, Pavel Minaev <int...@gmail.com> wrote:
On Apr 1, 9:05 am, Martin Bonner <martinfro...@yahoo.co.uk> wrote:
Yes. Access via pointer to integer is undefined behaviour if the
underlying object was actually type array of char.
Is it, however? int is POD, and therefore its lifetime begins as soon
as we have a properly aligned block of memory of suitable size, per
the Standard. I always took it to mean that any such suitable block
could have its address cast to int*, and used as such.
This is my understanding. I may be incorrect.
//ex 1
#include <new>
using namespace std;
struct foo { int x; };
int main()
{ char * c = new char[sizeof(foo)];
foo * p = new (c) foo;
p->x = 1;
int y = p->x;
p->~foo();
delete[] c;
return y;
}
//ex 2
#include <new>
using namespace std;
struct foo { int x; };
int main()
{ char * c = new char[sizeof(foo)];
foo * p = new (c) foo;
p->x = 1;
int y = p->x;
// p->~foo();
delete[] c;
return y;
}
//ex 3
#include <new>
using namespace std;
struct foo { int x; };
int main()
{ char * c = new char[sizeof(foo)];
// foo * p = new (c) foo;
foo * p = reinterpret_cast<foo*>(c);
p->x = 1;
int y = p->x;
// p->~foo();
delete[] c;
return y;
}
Ex 1 is well formed and has no unspecified nor implementation defined
behavior. (Do I need to include <new>? Comeau complains if I don't.)
Ex 2 is well formed and has no unspecified nor implementation defined
behavior. It may have a leak. If foo was not POD, would it necessarily
have a leak?
Ex 3 has undefined behavior. It accesses a char[] through an int
pointer, and this violates the strict aliasing rule, see C++03
3.10.15.
I also don't know which objects are we allowed to placement new other
objects into? Any suitably aligned object of sufficient size
(presumably no)? Properly aligned PODs of sufficient size? (How do we
know it's properly aligned besides implementation docs?) Just new'ed
char arrays and new'ed unsigned char arrays of sufficient size?
I don't fully understand what C++ 5.3.4.10 is saying. It mentions that
the difference between the result of the new expression and the
allocation function is an integer multiple of the most stringent
alignment type. It has a note explaining this allows the common idiom
of placement-newing objects into char arrays and unsigned char arrays.
I don't understand how the rules imply the note in parenthesis.
On Apr 1, 3:08 pm, Pavel Minaev <int...@gmail.com> wrote:
Of course, in this particular case, the block isn't properly aligned,
so it doesn't apply here. But in general?
But it is suitably aligned. See C++ 5.3.4.10. The return of new char[]
is suitably aligned for any type (for an allocation size sufficient to
hold the object). (However, the op's cast to char*, increment by 3,
and cast back to int* is another story, which is still broken.)
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]