Date: Sun, 5 May 2013 12:40:30 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: [patch] add ether_(aton, ntoa) On Sun, May 05, 2013 at 06:24:19PM +0200, Szabolcs Nagy wrote: > * Strake <strake888@...il.com> [2013-05-05 09:02:04 -0500]: > > On 19/04/2013, Rich Felker <dalias@...ifal.cx> wrote: > > > &x has the wrong type; strtoul requires char **, not const char **. > > > A separate temp var is required for the output, as in. > > > > > > char *y; > > > n = strtoul (x, &y, 16); > > > x = y; > > > > > > or similar. As far as I know the naive cast one could make to "fix" > > > the type mismatch is not valid; it would be an aliasing violation. > > > > What bad could happen? > > > the naive cast is strtoul(x, (char**)&x, 16) > > (const char **) and (char **) are not compatible types > and they are not required to have the same representation > and alignment > > so the conversion itself may invoke undefined behaviour I'm not so worried about this. Assuming that all pointers have the same size and representation is a reasonable modern assumption, and whether they do is implementation-defined, not undefined. Still it may be nice for higher-level code which could be reused on obscure targets outside of musl to avoid such assumptions when possible. Perhaps it would be nice to come up with a systematic way of documenting which code in musl depends on implementation-defined characteristics, since there was recently demand for this in another thread.. > but even if the representation and alignment is the same > an object with effective type (const char*) cannot be > accessed through a (char*) lvalue expression within strtoul > > so the aliasing rules are violated as well > (a compiler may reorder the loads from x and the stores > to *(char**)&x arbitarily) Indeed this is the real issue, but it's fairly hard to hit. If the compiler can only see the code in the caller and not inside strtoul, it can't do any reordering, because it must assume the callee could convert the pointer back to the right type and perform legal writes through it. The aliasing violation only has pratical consequences if you assume optimization can take place across translation units, e.g. LTO. In any case, it's policy not to do this kind of aliasing violation, especially when the identical result can easily be achieved using a temp variable of the right type. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.