gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John Goerzen
Subject: [Gnu-arch-users] Re: 64-bit cleaning [PATCH]
Date: Mon, 08 Sep 2003 17:53:19 -0500
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

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.

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

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

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 :-)

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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]