On Thu, Feb 12, 2004 at 07:54:24PM -0500, Greg Troxel wrote:
> > not that I know of, getting coda running on amd64 is on my (every
> > growing) "to do" list.
> 
> That's what I thought, but I had to ask.
> 
> > > 64k/64u
> >
> > Ultimately, in my opinion, this is where coda/venus should be - be
> > LP64 clean but this will mean some underlying infrastructure changes
> > that will mean that old clients & servers will break when combined
> > with new clients/servers.  Which may require a "flag day" at a site to
> > change everyone over to the new code.  The only out would be if the
> > rpc2 interface is versioned or not - I have not checked - if it was
> > versioned then some clevers may be pulled in the server code to
> > provide some backward compatiability which would obviate the need for
> > a flag day.
> 
> Agreed.  But I'm not sure we need a wire change, just redefining long
> to be int32_t, in effect standardizing on the i386 sizes.  I did this
> with amanda/kerberos and it worked.

Well, the size of long shouldn't change.  Only the size of pointers and
how long long is implemented.  I don't know about netbsd, but virtually
every entity I'm aware of (Sun, HP, Linux) a long is 32 bits no matter
how it's compiled.  Otherwise, bloody everything will break.  I think
that a long on Alpha is 64 bits, but that's the exception, because it
was never anything else on Alpha, but causes a mess of problems getting
software to work on Alpha.  So, at least for Linux, you shouldn't
have to set long to be 32 bits.  But it might break things that assumed
a certain pad in structures or assumed a lack of pad, or alignment
assumptions.  But, with only the size of pointers changing, you discover
how pervasive the assumption is that they are 32 bits.

I think that the latest versions of lint have modes that can check your
code for possible places they will break if compiled for 64 bit use.

a