Re: [Firebird-devel] 64/32 bit handle compatibility

[James K. L. <jkl...@sc...>]

On Thu, 15 Apr 2004, Jim Starkey <ja...@ne...> wrote:
> >Finally, it's clear to me.  Some newer (not Alpha or Sparc) 64-bit
> >architectures support 32- and 64-bit addressing modes in a single
> >process.
> > On such a chip, a 32-bit clients won't be able to link safely to an
> >embedded 64-bit server, because their definitions of void* differ.  Is
> >that it?  
> >
> In theory, yes, in practice, I think not.  Both the Ultra-sparc and 
> AMD64 support 64 bit with additional instructions leaving the original 
> instruction set unchanged.  But doing so is chaos as the calling 
> sequences are different.  I may be wrong, but I believe that neither the
> 
> linkers not dynamic loaders allow mixing of 32 and 64 bit modules.  I 
> don't know whether the OS knows whether the process is 32 or 64 bit, but
> 
> I think it's moot since mixing doesn't work.

Thanks for clearing that up.  Now I definitely don't understand what all
the hullabaloo is about.  Do you have a technical this-won't-work issue,
or a political this-won't-fly issue, or an aesthetic this-won't-do issue? 


From everything you've said, there's no possibility (as of now) of a
64-bit and a 32-bit process exchanging pointers to anything.  Neither,
supposing it were possible, is there any clear circumstance under which
that would be advantageous.  

Where I come from, when the implementation and the documentation are at
variance, and there's no functional problem, it's usually best just to
update the documentation.  

> If you were thinking of spending your weekend getting up to speed on the
> latest in Vulcan, may I suggest that your time would be more fruitfully
> applied to going outside smelling the flowers?

Aye, good advice.  But you will be missing the first blessings of Spring,
sir.  

--jkl