<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>What is the status and chance of a 32 bit integer with the range 0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. 0xFFFFFFFFFFFFFFFF?<BR>
<BR>
<BR>
Already available?<BR>
Impossible to provide?<BR>Only available in unsafe modules?<BR>Only available with restricted operations in safe modules, and more operations in unsafe modules?<BR>
<BR>
<BR>
Specifically, I think looping from 0 to N is safe -- no overflow.<BR>
Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow.<BR>
Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow.<BR>
Adding or subtracting an INTEGER to "UNSIGNED" is not safe.<BR>
Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow.<BR>Comparing UNSIGNED to UNSIGNED for any of =, <, >, !=, is safe.<BR>
Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done carefully.<BR>
Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL or UNSIGNED.<BR>The unsafe operations above could be runtime checked perhaps.<BR>
I guess that's a different larger point/dilemna -- when to allow potentially unsafe operations but with runtime checks vs. the compiler just disallowing them entirely. e.g. adding an integer to an integer is not even safe, but checked maybe at runtime (ok, at least assignment to subrange types is checked). Yes, I know I know, the runtime checks on at least many integer operations is yet lacking.<BR>
<BR>
Is there any, um, value in such a type?<BR>
Is it just me blindly trying to cast Modula-3 as C (yes), but there's no actual value (uncertain)?<BR><BR>
<BR>
Btw, I agree there's no point in this type in representing file sizes or offsets. They should be at least 63 bit integers. One bit doesn't buy much for file sizes. It might be something for address spaces though?<BR>
<BR>
It bugs me to define types like uintptr_t = CARDINAL or uintptr_t = INTEGER. It seems quite wrong.<BR>
Perhaps the unsigned types larger than 16 bits just should not be defined in Cstdint. ??<BR>
But there is already Ctypes.unsigned_int, unsigned_long_long, whose underlying type I think is signed, but which convention says you just don't do signed operations on, but which the compiler doesn't enforce, right?<BR>
<BR>
You know, maybe Word.T should not be INTEGER but this mythological UNSIGNED/UINT??????<BR>
<BR>
- Jay<BR></body>
</html>