Low-level types and over/underflow

2007-02-27 Thread Geoffrey Broadwell
What happens when a low-level type overflows or underflows?  For
example, if you decrement an int1 twice, what happens?

If you increment a uint8 past 255, do you get:

1. A uint8  with value 0?
2. A uint16 with value 256?
3. A failure?

What about incrementing an int8 past 127?  Do you get:

1. An int8  with value -128?
2. A uint8  with value 128?
3. An int16 with value 128?
4. A failure?

In both cases, I think option 1 is best, but I can see that option 2 in
the signed case might make sense in certain circumstances.  Personally,
I'd prefer to keep option 1 always, because if I want option 2 I should
cast to uint or a larger int first.


-'f




Re: Low-level types and over/underflow

2007-02-27 Thread Darren Duncan

At 6:15 AM -0800 2/27/07, Geoffrey Broadwell wrote:

What happens when a low-level type overflows or underflows?  For
example, if you decrement an int1 twice, what happens?

If you increment a uint8 past 255, do you get:

1. A uint8  with value 0?
2. A uint16 with value 256?
3. A failure?

What about incrementing an int8 past 127?  Do you get:

1. An int8  with value -128?
2. A uint8  with value 128?
3. An int16 with value 128?
4. A failure?

In both cases, I think option 1 is best, but I can see that option 2 in
the signed case might make sense in certain circumstances.  Personally,
I'd prefer to keep option 1 always, because if I want option 2 I should
cast to uint or a larger int first.


I believe that the answer to this is whatever the underlying 
hardware does.  These lowercased types are unboxed and directly 
reflect their CPU native equivalents, AFAIK.  That said, I suspect 
that either a wraparound or an overflow code is what you'd get, and 
not a type upgrade. -- Darren Duncan