[PATCH] Fix undefined aliasing in libwrap.c
Hello, The attached patch changes the code not to access a part of a char[...] array using an int *, which is undefined in ISO C. Using memcpy() is safe. I would have posted it on in the BTS, but it doesn't allow me even to log in... Thank you, Mirek
Miloslav Trmac wrote:
The attached patch changes the code not to access a part of a char[...] array using an int *, which is undefined in ISO C.
Casting pointers is undefined? On some architectures it could make sense due to data alignment issues, but I really didn't know that. Where did you find it?
I would have posted it on in the BTS, but it doesn't allow me even to log in...
I guess there was some problem due to DBMS upgrade. I'll work on that. Thx 4 info. Best regards, Mike
On Sat, 2009-05-02 14:44:02 +0200, Michal Trojnara wrote:
Miloslav Trmac wrote:
The attached patch changes the code not to access a part of a char[...] array using an int *, which is undefined in ISO C.
Casting pointers is undefined? On some architectures it could make sense due to data alignment issues, but I really didn't know that. Where did you find it?
I suppose Miloslav didn't want to say 'undefined', but 'leads to undefined behavior'. In fact, accessing objects at addresses not suitable aligned leads to strange effects on some machines (e.g. ARM9 or C165), but this fact is not even mentioned in IEC9899:1999 (a.k.a. C99). Even worse C99 _defines_ void* to "have the same representation and alignment requirements as a pointer to a character type", which is not suitable the vast majority of the objects one could have pointers for. A nightmare for static code checkers ... Ludolf -- --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Floßwörthstraße 41 e-mail: [email protected] D-68199 Mannheim, Germany ---------------------------------------------------------------
Ludolf Holzheid wrote:
In fact, accessing objects at addresses not suitable aligned leads to strange effects on some machines (e.g. ARM9 or C165), but this fact is not even mentioned in IEC9899:1999 (a.k.a. C99).
You're right. memcpy() is a safe way to assure proper alignment.
Even worse C99 _defines_ void* to "have the same representation and alignment requirements as a pointer to a character type", which is not suitable the vast majority of the objects one could have pointers for. A nightmare for static code checkers ...
The whole idea of C is a nightmare for static code analyzers... C is basically a structured, cpu-independent assembler. A programmer writing C code can easily see how it's going to be translated for a specific CPU. Nothing is added automatically by the compiler. This is why I'm such a big fan of C. 8-) Best regards, Mike
----- "Michal Trojnara" <[email protected]> wrote:
Miloslav Trmac wrote:
The attached patch changes the code not to access a part of a char[...] array using an int *, which is undefined in ISO C.
Casting pointers is undefined? No (as long as alignment restrictions are not violated), but accessing an object of one type via a pointer of other type is undefined for most combinations of the types.
Where did you find it? In the C standard :) Besides, GCC warns quite loudly.
http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html is a good description of the issue. Mirek
participants (3)
-
Ludolf Holzheid -
Michal Trojnara -
Miloslav Trmac