[M3devel] unsigned integers?

[Jay]

Very interesting.
The suggestion of one of the links is that the extra range of a full unsigned type isn't particularly needed, once you have 31 bits instead of only 15.
Now, in C, it is common to do a manual range check, and having unsigned cuts that check in half, makes it easier to get correct.
However Modula-3 does that checking for you, taking away more of the point of the full unsigned type.
So I guess there's just no need.
It might be nice to make Word.T != INTEGER though. ?
Gotta run.
 
- Jay> Date: Mon, 2 Jun 2008 21:43:20 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] unsigned integers?> > It's already available, but takes a bit of care.> > Modula-2 had an INTEGER and a CARDINAL, the latter unsigned and having> full unsigned range for its word size. I think it was not fully> defined in the original language report. It turned out a semantic> nightmare. It was a nightmare to code too. Been there, done that.> > Modula-3's CARDINAL, as I'm sure everybody knows is just the positive> half range of INTEGER and behaves just like a subrange of INTEGER.> This solves a lot of problems, at the cost of taking away half the> unsigned range.> > For full-range unsigned, you use the type INTEGER, but use the> operations in interface Word. It's the same type, but different> interpretations applied to the same bit pattern. It would be a> good practice to declare things as INTEGER when they are signed> and Word.T when unsigned, but there is nothing in the language to> require it.> > In the case of addition and subtraction, builtin operators "+" and> "-" will produce the same results as Word.Plus and Word.Minus,> respectively, except that the conditions under which overflow is> detected will differ. Not that that matters much, as, AFAIK, none> of the implementations detect integer overflows anyway.> > So use INTEGER and the unary and binary operators if you want it to> be signed, and use Word.T and Word.<function> if you want it unsigned.> > Of course, you are free to assign between a variable that is being> treated as signed and one treated as unsigned any time, without any> overflow checks, unless you program them yourself. This certainly> violates the intuition about what safety means. However, on closer> look, it is not at all the same degree of unsafety as, say, arrays> going out of bounds.> > My definition of safe is that nothing can happen that cannot be> explained using only the concepts of the language. For example,> to understand what an array bounds error actually does, you would> need to know that an array actually shares memory with other variables,> code, etc., and then a huge amount about how the compiler, linker,> loader, heap allocator, etc. lay things out, along with what is> declared in all the code, including libraries you are not working on.> None of this is part of a so-called high-level language.> > The INTEGER/Word.T thing can be explained knowing about binary> twos-complement representation, which is definitely a machine-level> concept. The Word interface defines the unsigned side of it as> a language concept too, but only hints at the signed representation.> But most importantly, neither the operators nor the functions in> Word.T ever produce any values that are not meaningful in the value> set of the type.> > There is no really good linguistic solution to this problem, but> I think Modula-3's is definitely the least painful I have seen.> > > Jay wrote:> > 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?> > > > > > Already available?> > Impossible to provide?> > Only available in unsafe modules?> > Only available with restricted operations in safe modules, and more > > operations in unsafe modules?> > > > > > 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.> > Comparing UNSIGNED to UNSIGNED for any of =, <, >, !=, is safe.> > Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done > > carefully.> > Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL > > or UNSIGNED.> > The unsafe operations above could be runtime checked perhaps.> > 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.> > > > 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 > > actual value (uncertain)?> > > > > > 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?> > > > It bugs me to define types like uintptr_t = CARDINAL or uintptr_t = > > INTEGER. It seems quite wrong.> > Perhaps the unsigned types larger than 16 bits just should not be > > defined in Cstdint. ??> > 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?> > > > You know, maybe Word.T should not be INTEGER but this mythological > > UNSIGNED/UINT??????> > > > - Jay> > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080603/660b72dd/attachment-0002.html>