Re: [PATCH] PR#344: 64-bit cleanup

[Dean Gaudet <dg...@arctic.org>]

On Tue, 8 Jul 1997, Alexei Kosut wrote:

> On Tue, 8 Jul 1997, Dean Gaudet wrote:
> 
> > Introduce a new type generic_data which is large enough to hold a pointer
> > or an integer, and which the compiler is likely to pass by value
> > efficiently.  This requires certain functions that take "void *" to start
> > taking generic_data.  It also changes the command_rec and related
> > structures to include a generic_data field instead of a void * field.
> 
> Is this really neccessary? It seems a bit drastic.

Theoretically it is necessary to dictate this.  For example in the future
there might be a box with 64-bit pointers and 128-bit integers... for what
reason I can't imagine.  Just as there are boxes now with 64-bit pointers
and 32-bit integers.  So you can't say if the largest "register" type is a
pointer or an integer.

We want the type to be held in a register because otherwise it imposes a
bunch of function-call overhead.  A struct or union is (generally) passed
by reference-to-copy rather than being passed by value.  unions can only
have their first element initialized at compile time, making them more
inconvenient.

> > The command_rec change required changes to every module to deal with the
> > static initializer for the info field.
> 
> Hmm. Does it actually require the change, or is it of the "make it, or
> you'll get a warning, but it'll work okay on 32-bit systems" variety? If
> the former, I'd be very hesitant to agree to the patch unless there are
> absolutely no other solutions.

make it or get a warning, but it'll work okay. 

This is one of those things where we just have to bite it and do it.  We
hashed all this out the last time I brought up PR#344 I thought. 

Dean

Re: [PATCH] PR#344: 64-bit cleanup

[Alexei Kosut <ak...@organic.com>]

On Tue, 8 Jul 1997, Dean Gaudet wrote:

[Dean's 64-bit patch]

> make it or get a warning, but it'll work okay. 
> 
> This is one of those things where we just have to bite it and do it.  We
> hashed all this out the last time I brought up PR#344 I thought. 

Yeah, I just wasn't paying as much attention as I should have been.

At any rate, I guess we have to do this. Haven't had a chance to look
hard at the patch, but +1 on the concept (unless there's a better one
*grin*).

-- Alexei Kosut <ak...@organic.com>