On Tue, May 04, 2004 at 07:33:45PM +1000, Darren Reed wrote:
> 
> Chuck,
> 
> If you (or someone else) embarks on a "int32_t" style change throughout
> TCP, is it worth considering using the "tcp_seq" more or creating a
> signed version of it to use, instead of just "int32_t" ?
> 
> I am am 'tyre kicking' (tm lukem) here, so feel free to refuse if you
> think this is not going to provide much additional benefit :)

I think using types that indicate the usage of the value is good thing.
for instance, I recommended against converting all the ufs_lbn_t and
ufs_daddr_t stuff to plain daddr_t, since the extra types gave more
information (in that case, it was the units of the value and whether
the value was a logical offset within a file or a physical offset on disk).
those got removed anyway though.

I don't really know enough about the TCP code to come up with similarly
informative types, but if someone else does, that would be useful.

it's be really neat if there was a way to get the compiler (or lint) to
treat different typedefs as incompatible types even if they map to the
same underlying type.  that way we could catch subtle bugs like a value
in units of sectors is used in a context where the value is expect to have
units of fs blocks.  or it could catch confusion between vaddr_t and paddr_t.
I haven't heard of anything that does that though.

-Chuck