Brett Lymn <blymn_at_baesystems.com.au> writes:

> On Sat, Jan 03, 2004 at 01:00:00AM -0500, Jan Harkes wrote:
> > 
> > The biggest problem is really RPC2, which defines RPC2_Integer as a
> > signed long integer. This percolates all throughout the rest of the code
> > and causes serious problems because all the data structures end up not
> > matching with other 32-bit clients (and probably the kernel module).
> > 
> 
> oh dear, that sounds ugly.

It shouldn't be so bad.  You just redefine RPC2_Integer to be
u_int32_t, which is the on-the-wire actual type.  calling it unsigned
long is just a coding error.

> > Simply changing the RPC2_Integer typedef results in hundreds of compiler
> > warnings and leaves several things unresolved, should file lenghts be
> > 32-bit as with the existing systems or become 64-bit and break
> > compatibility.

So this exposes lots of other places where unsigned long is used and
shouldn't be.  Jan: are you saying this is undoable, or just a lot of
remedial work?  The resulting fixes should be commitable any time,
mostly, I would think.

> To be honest, I think changing file lengths to be 64bit should be done
> (not soley because it is convenient for my cause :) but from the
> perspective that most OS'es I know already use a 64bit quantity for
> the file size - even if they are running a 32bit version.  It would
> make sense if coda matched that capability.

on os interface, yes.  but coda would have real trouble with >4GB
files, so is not a big deal for now IMHO.

> > It also causes many problematic cases caused by casts
> > that do something like, (long *)&rpc2_integer_type, which works just
> > fine on a 32-bit machine where sizeof(long) == sizeof(int), but
> > introduces a pretty serious bug on 64-bit machines. And as the casts
> > hide the compiler warnings, this goes mostly unnoticed until we try to
> > use the value and get bad data, or when we silently corrupt adjacent
> > memory by storing new data to the 'long *'.

Code review! - find some undergrads :-)

I guess a big decision is if rpc2_integer_type is signed or unsigned.
Perhaps that needs cleaning up (splitting) too.


-- 
        Greg Troxel <gdt_at_ir.bbn.com>