One alternative is an all-BIGNUM interface where offsets and sizes have
no arbitrary limits, while the implementation uses whatever widths are
most convenient to compile for "the average processor" (yeah, that's a
joke). This might be convenient on distributed, persistent object systems.
With all offsets and sizes typedef BIGNUM (min and max are - and +
infinity), users can forget about size bounds in code, and only kernel and
filesystem developers have to worry about it. Pretty much every standard
gnu program expecting C sizes and offsets would have to be hacked
to use something like this. So it would happen over quite a long
time, as this is a major paradigm shift when programming in C.
Just what does sizeof(BIGNUM) return? A pointer? A struct size? It'll be
kinda slow when every size parameter is a function call instead of a
compiler primitive. That won't matter some places, but I don't think I'm
going to want to run that on a heavily loaded p5 or p6.
CONFIG_32
CONFIG_64
CONFIG_128
CONFIG_BIGNUM
(talk about kernel source bloat)
Regards, Clayton Weaver cgweav@eskimo.com (Seattle)