Re: [Gnu-arch-users] 64-bit cleaning [PATCH]

[Tom Lord]

    > From: John Goerzen <address@hidden>

    > On Mon, Sep 08, 2003 at 03:30:03PM +0900, Stephen J. Turnbull wrote:
    > > >>>>> "John" == John Goerzen <address@hidden> writes:

    > >     John> (-Wall is very useful on gcc)

    > > Either -Wstrict-aliasing or -fno-strict-aliasing is a really good
    > > idea.  (AFAIK gcc 3.x doesn't warn on aliasing with -Wall, but it
    > > really should.)  Arch in particular is known to have a few places with
    > > aliasing issues.

    > My understanding of those options (I assume you meant -fstrict-aliasing) 
is
    > somewhat limited, but from the manpage, it indicates:

    >           vates optimizations based on the type of expressions.  In 
particu-
    >            lar, an object of one type is assumed never to reside at the 
same
    >            address as an object of a different type, unless the types are
    >            almost the same.  For example, an "unsigned int" can alias an
    >            "int", but not a "void*" or a "double".  A character type may 
alias
    >            any other type.

    > Given that hackerlab does exactly that all over the place, it would 
require
    > conversion of a lot of code to use unions instead of void *.

    > I'm not opposed to that, and personally think it a good idea, but I'd 
rather
    > not do it until Tom indicates he'd accept such changes.  Tom?


The stuff in Rx and VU has some data structures that contain a `void
*' which can contain arbitrary, application-provided data.  Some other
parts of Rx use this to pass a long value (formerly, an int -- but
this changed killed off a bunch of dumb gcc warnings).  In VU i've
introduced "double casts" where an int is stored in one of these
rocks.

A change to use a union there raises three issues:

        1) It's an interface change to what I'd prefer to keep as
           a stable interface.   This is a weak preference, though,
           because the interfaces in question are still fairly 
           obscure -- I don't _think_ that many 3rd party systems
           are relying on them.

        2) What's going to go in this union?   The only answer 
           I can see is to cover the basic scalar types that
           will fit.   But that's a minor annoyance because instead
           of just casting to and from (void *), proper client 
           programs will have to do some per-machine configuration
           to pick which is the appropriate union member to use.
           I don't know what the heck a client will do if it wants
           to store a tiny structure or union. Ick.

        3) Using a union here is ugly.

The other issues, I suppose, are the array headers in ar.c and, though
it isn't built by default, problably the malloc in the piw*
directories.  I dunno -- it looks like C to me.

So, I'm not terribly enthusiastic about such changes -- but I'd be
willing to look at them and reconsider.   Perhaps if you show just 
a few samples of the changes you have in mind so I can get a
representative feel for their implications without your having to do
all the work up-front.


-t