[M3devel] unsigned integers?

Tue Jun 3 02:15:23 CEST 2008

What is it you are looking for?

1 Operator overloading of + - * DIV for this new type?

2 Runtime checks of overflow?

Or both?

You can obviously get #2 by writing a tiny little library of your
own?  (Just like the Word interface but with overflow checks.)  Does
it matter whether the underlying implementation uses INTEGER or
ARRAY OF BITS 8 FOR [0..255]?

Doesn't 

    a : Unsigned.T := 3;
    b : CARDINAL := 4;
    c := a - b;

overflow?

The Green Book is quite clear on the point that Word.T operations
can never overflow, that is, all operations are "safe", using your
terminology, so no, they aren't the same types.

But it's rather confusing that you use a different definition of
the word "safe" from that used in the Green Book.  (In fact the
Green Book only defines "unsafe" but I assume "safe" to mean "not
unsafe", which it does, too.)

     Mika

Jay writes:
>--_a753fe8a-a24d-445a-8b9d-c524a5a0a41a_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>What is the status and chance of a 32 bit integer with the range 0..0xFFFFF=
>FFF and of a 64 bit integer type with range 0 .. 0xFFFFFFFFFFFFFFFF?
>=20
>=20
>Already available?
>Impossible to provide?Only available in unsafe modules?Only available with =
>restricted operations in safe modules, and more operations in unsafe module=
>s?
>=20
>=20
>Specifically, I think looping from 0 to N is safe -- no overflow.
>Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow.
>Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow.
>Adding or subtracting an INTEGER to "UNSIGNED" is not safe.
>Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow.Comparin=
>g UNSIGNED to UNSIGNED for any of =3D, <, >, !=3D, is safe.
>Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done careful=
>ly.
>  Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL or U=
>NSIGNED.The unsafe operations above could be runtime checked perhaps.
>  I guess that's a different larger point/dilemna -- when to allow potentia=
>lly unsafe operations but with runtime checks vs. the compiler just disallo=
>wing 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 o=
>perations is yet lacking.
>=20
>Is there any, um, value in such a type?
>Is it just me blindly trying to cast Modula-3 as C (yes), but there's no ac=
>tual value (uncertain)?
>=20
>Btw, I agree there's no point in this type in representing file sizes or of=
>fsets. They should be at least 63 bit integers. One bit doesn't buy much fo=
>r file sizes. It might be something for address spaces though?
>=20
>It bugs me to define types like uintptr_t =3D CARDINAL or uintptr_t =3D INT=
>EGER. It seems quite wrong.
>Perhaps the unsigned types larger than 16 bits just should not be defined i=
>n Cstdint. ??
>But there is already Ctypes.unsigned_int, unsigned_long_long, whose underly=
>ing type I think is signed, but which convention says you just don't do sig=
>ned operations on, but which the compiler doesn't enforce, right?
>=20
>You know, maybe Word.T should not be INTEGER but this mythological UNSIGNED=
>/UINT??????
>=20
> - Jay=
>
>--_a753fe8a-a24d-445a-8b9d-c524a5a0a41a_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style>
>.hmmessage P
>{
>margin:0px;
>padding:0px
>}
>body.hmmessage
>{
>FONT-SIZE: 10pt;
>FONT-FAMILY:Tahoma
>}
></style>
></head>
><body class=3D'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 availab=
>le with restricted operations in safe modules, and more operations in unsaf=
>e 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>Comp=
>aring UNSIGNED to UNSIGNED for any of =3D, <, >, !=3D, is safe.<BR>
>Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done careful=
>ly.<BR>
>  Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any =
>CARDINAL or UNSIGNED.<BR>The unsafe operations above could be runtime check=
>ed perhaps.<BR>
>  I guess that's a different larger point/dilemna -- when to allow pot=
>entially unsafe operations but with runtime checks vs. the compiler just di=
>sallowing them entirely. e.g. adding an integer to an integer is not even s=
>afe, but checked maybe at runtime (ok, at least assignment to subrange type=
>s is checked). Yes, I know I know, the runtime checks on at least many inte=
>ger 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 ac=
>tual value (uncertain)?<BR><BR>
> <BR>
>Btw, I agree there's no point in this type in representing file sizes or of=
>fsets. They should be at least 63 bit integers. One bit doesn't buy much fo=
>r file sizes. It might be something for address spaces though?<BR>
> <BR>
>It bugs me to define types like uintptr_t =3D CARDINAL or uintptr_t =3D INT=
>EGER. It seems quite wrong.<BR>
>Perhaps the unsigned types larger than 16 bits just should not be defined i=
>n Cstdint. ??<BR>
>But there is already Ctypes.unsigned_int, unsigned_long_long, whose underly=
>ing type I think is signed, but which convention says you just don't do sig=
>ned 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>=
>
>--_a753fe8a-a24d-445a-8b9d-c524a5a0a41a_--