[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
