range check 32-bit and 64-bit

Frank Heckenbach ih8mj at fjf.gnu.de
Wed Apr 11 12:06:29 CEST 2007


Jonas Maebe wrote:

> >> So the bugfix might be to make subrange types signed when the range
> >> allows (which would always be the case in valid ISO programs).
>> Frank
> 
> Note that doing this may cause problems with packed arrays and  
> records, like we had in FPC. If you treat 0..3 as signed, then you  
> can no longer pack it in 2 bits using the current format used by FPC  
> and GPC. The reason is that if a type is signed, both compilers treat  
> the uppermost bit of a packed value as the sign bit. So 2 and 3 would  
> be interpreted as -2 and -1, respectively.

Indeed. But I was talking about unpacked types only. We have special
code for subranges in packed arrays anyway, and that shouldn't change.

> Of course, it is possible to change the format of packed values  
> (e.g., always store them as unsigned, with a bias of -lower_bound in  
> case of signed types), but this may cause backward compatibility issues.
 
No, I wouldn't like to do this. (Even if one could gain a bit occasionally,
such as storing -1 .. 2 in 2 bits instead of 3 as now, but it doesn't seem
worth the effort.)

> Or, alternatively, you can of course do the sign extension only if  
> the lower bound is < 0 rather than if the type is signed (maybe that  
> even already happens today in gpc that way). Depending on how the gpc  
> internals work, differentiating between "signed type" and "lower  
> bound < 0" may cause some hairiness.

Yes, it does, and that's basically the problem here. In the original
case, the lower bound was >= 0, but the type was treated as unsigned.

To be clear, I'm only talking about unpacked subrange types whose both
bounds fit into (signed) "Integer". When the lower bound is < 0, it's
signed anyway, no issue here. But when it's >= 0, the type should get
signed as well, not unsigned like now.

OTOH, when the upper bound doesn't fit into "Integer" anymore (this case
doesn't affect ISO compliance, as ISO doesn't have any bigger type than
"Integer"), we should rather use an unsigned type than a bigger signed
type, even when available (e.g., on IA32, use unsigned 32 bit rather than
signed 64 bit, as long as the upper bound fits in unsigned 32 bits).

Frank

-- 
Frank Heckenbach, f.heckenbach at fh-soft.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE  D101 CD02 4C9D 0FE0 E5E8





More information about the Gpc mailing list