Brett Lymn <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>