osargs functions and 32 bit values

[Jonathan Coxhead]

   On 23 Aug 00, at 19:41, Chris Rutter wrote:

 | I think the benefit provided by enabling implicit signed arithmetic in
 | a few of these constructions is pretty marginal, to be honest.  If 
there's
 | no practical scope for the integer limit to be exceeded, then I agree 
that
 | the loss of `correctness' is probably less important than the ease gain, 
but
 | where the limit may be a potential issue, I don't think conveniences like
 | that are that important.

   I disagree---My view is that, even if the value might be bigger than 
INT_MAX, it should still be held in an int. I realise that this is is 
technically undefined behaviour, and I expect that no-one else probably 
holds that view. The reason that its defensible at all is that OSLib only 
runs on a particular processor (ARM), and we know that the ARM is a 2's-
complement machine. Therefore, the client can always cast their ints to 
unsigned, and do the comparison they want.

   I prefer the "usual" case (of arithmetic on ints < INT_MAX) to "look 
nice", and casts needed for large values, over the necessity to add casts 
to int in all cases, even those where the limits aren't even approached.

   Y M M V, of course.

 | Perhaps a little investigation of which quantities, represented by `int',
 | /are/ in danger of running over limits.

   That would be of interest, as it's certainly important. Whether the 
results become encodified as different functions, or if they are just 
documented in a nice consistent way, is a decision we could make afterawrds.

 | An off-topic question: if `UINT_MAX' was 0xffffffffu, and I took the 
number
 | 0xf0f0f0f0 and shifted it left by 8 places, would ANSI guarantee me that
 | those eight most significant bits would simply be discarded, or do I,
 | /strictly speaking/, have to AND with a protective mask first?
 | 
 | (I could look this up but I suspect Jon will know. ;-)

   I'd have to look it up too, because the answer's more complicated than 
you might have thought. The question is, what type is 0xF0F0F0F0? It's not 
int, because it doesn't fit. There are some complicated rules to decide 
what it is, but (without checking) I think it's unsigned int. Therefore, 
all operations work modulo 2^^32, and the answer is 0xF0F0F000. If the type 
of 0xF0F0F0F0 *was* int (i e, if an int with that value was shifted), the 
answer would be undefined (I think).

        /|
 o o o (_|/
        /|
       (_/