osargs functions and 32 bit values

[Chris Rutter]

On Mon, 21 Aug 2000, Jonathan Coxhead wrote:

>    The reason is that it can introduce obscure errors. It's bad enough that
> 
>       if (strlen (s) > 1)
> 
> is different from
> 
>       if (strlen (s) - 1 > 0)
> 
> (the first does what you think, the second can never fail) without 
> compounding the problem further.

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 imagine Norcroft will probably complain, anyway, surely?

>    My rule of thumb is, if a quantity is only subject to bitwise operators 
> (| & ~ ^) then it is declared |bits|; if it may also be used with 
> arithmetic operators (+ - * / << >>) then it is declared |int|, even if it 
> so happens that it will only take positive values.

That's certainly a reasonable (in both senses) point of view.  It's the
pragmatic point of view that Perl takes (if you're not going to be doing
bitwise operations you'd never want an unsigned number).

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

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. ;-)

c.