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

[Tom Lord]

    > From: John Goerzen <address@hidden>

First thing, on a tangent:

It has been called to my attention that your doc patches got dropped
do to some work-flow foo on my end.   Sorry about that.   That'll be
fixed within the next few days.  (Thanks, Zack Brown.)

For reference, in the future, the best way to submit patches is via
the bug tracker with an optional message to gnu-arch-users.  It's much
harder for me to flake out on something that way.  (The bug tracker
connected to the savannah.gnu.org gnu-arch project, that is.   Zack
has done this for your doc patches in bug #5158.)


    > Tom Lord <address@hidden> writes:

    > > 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.

    > Your other option, I suppose, would be to actually use the void * as a
    > pointer to something :-)

    > It could point to an int, or the first character of a string, or
    > NULL.  Of course, that introduces the complexity of allocating and
    > freeing stuff.

Hey, I know where Pascal is when I need it :-)


    > >         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.

    > I don't follow why there would need to be per-machine configuration.
    > Members of a union need not be the same size; the union will be the
    > size of the largest.

In some of this code, it's actually critical that the data in question
occupy one word.

But, anyway, you haven't really addressed the question.  The
programmers defining the union (people contributing to hackerlab) is
not a superset of people who might be using the union (people using
hackerlab).

If the union covers just the basic scalar types, and users don't want
to be sign-extending/contracting shorter (possibly typedefed to an
unspecified scalar) values to long, they need the config foo.  If
users want to store a small non-scalar value, they're up the creek.

In short, a union in this case kina-sorta hacks around a few immediate
compiler warnings -- but i don't see how it really solves the
purported underlying problem.    Personally, I think this is one small
symptom of why the aliasing rules, as specified, are a mistake.




    > >         3) Using a union here is ugly.

    > It's not ugly in the places that treat the void * as just a hunk of
    > data.  They'd do the same with a union.

Nope.  Programmers using the rock (the `void *' slot) to hold a
typedef scalar that they can't make too many assumptions about don't
reliably get the same code using the union unless they include config
foo to pick the right union field based on the sizes of various
scalars on the target architecture.

Here's what you (officially) can't say in C99 (double casting is just
a trick that happens to fool GCC): "Here's some bits that I know fit
in a void *.  Please store them in one.  Ok, see that void *?  I put
some bits there -- please give them back."  As I vaguely recall,
there's exceptions for storage addressed by character pointers.
Perhaps (and my intention is to make you cringe) I could replace the
void * slots with a character array foo[byte_per_void_star].


    > I suppose it indeed could be ugly in the places where it is used.

    > > 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.

    > I'm not enthusiastic enough about them to do that either :-)

Cool!

    > Basically, I'm happy with the method I used in my patch (and from your
    > comments, it looks like you are doing the exact same thing [double
    > casting])).  It gets the job done.

It's double-casting in VU.  I have to make the painful admission that
in Rx, the warnings did lead to some (pragmatically inconsequential
but conceptually, I suppose ... sigh ... worthwhile) cleanups of some
declarations.

-t