DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15757>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15757 Assumption of sizeof (void*)/int begin equal (64-bit-unclean) ------- Additional Comments From [EMAIL PROTECTED] 2003-11-22 01:58 ------- Perhaps the summary of this bug should be changed, since it may be a technical problem even when sizeof(void*) == sizeof(int). My original summary was probably naive. > It is fine to store an int in a pointer, > whether or not they are the same size. Nope, pointers are scalars but they are not arithmetic scalars. Storing an int in pointer storage is not guaranteed like sorting an int in long storage presumably is. In particular, I think, the semantics of storing an int in pointer storage are undefined in C. (I suspect that the null pointer is a special case.) The WebDAV code assumes the int values will be aligned 'correctly' within the pointer storage and that the bytes will be in the 'right' order. I think that if x is (void*), and y is (int) and (y == 2) is true, then (x = (void*)y) does not necessarily lead to (((int)x) == 2) being true, even though it *often* would. (I don't know why anyone would have an architecture for which this was not true.) Nevertheless, it would be legal for the semantics to vary between different compilers (and ABIs?) on different platforms. Other projects have got their knickers in a knot over things like this, because it is easily abused. For example, their developers have begun using expressions like (*(int*)x), where x is (void*). This is unlikely to be portable (e.g. even if you ignore the 'semantics of poking an int into a pointer are undefined' problem, you might just consider endianism issues). Other projects have actually introduced crashes by being loose with things like this (though, as has been pointed out, assignment itself is not likely to produce crashes, unless there is some sort of runtime bounds check in operation). > This is not the only place in Apache with this issue IIRC. Without meaning to sound rude or arrogant, it sounds like the problem is getting worse, then. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
