<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'> > I don't want to add fuel to the fire, but .... <BR> > there. But, fortunately, Modula-3 provides UNTRACED objects/ <BR> > references which *never* themselves cause GC. In fact, for the <BR><BR>
Right, "optional safety" is a nice feature of Modula-3.<BR>
C# has optional safety but I think maybe in fewer ways -- optional integer overflow checks, not sure what else.<BR>
Otherwise optional safety seems to be pretty rare.<BR>
<BR>
This does remind us -- I don't think Modula-3's integer overflow rules are as obviously safe as they could be.<BR>
I think it's a target-varying thing and most targets don't check.<BR>
Integer overflow has started to become a concern like buffer overflow..so probably something should be done.<BR>
HOWEVER something pervasive and automatic may be too risky in terms of compatibilty with existing code.<BR>
I mean Modula-3.<BR>
<BR>
In C and C++, for "useful suggestions", there have been two obvious patterns:<BR>
Functions to add, subtract, multiple integers, that can fail. Tedious but explicit.<BR>
Probably good candidates for building into the language/compiler like Word, even if they are explicit functions.<BR>
<BR>
Templatized types with all the operators overloaded. Also a good candidate for inclusion in the language/compiler.<BR>
What to call? There is "SafeInt".<BR>
<BR>
I think Modula-3 has more chance of getting away with just making it so for INTEGER but I would have to read up more.<BR>
<BR>
In C as I understand:<BR>
The encoding and overflow behavior of signed integers is undefined/implemention-defined. You could have signed magnitude, one's complement, two's complement, or anything you want. You can have any behavior for integer overflow. Some sort of "wrap around", abort(), etc. For unsigned integers, overflow is well defined, never an error, and "wraps around". In practise, signed integers are always two's complement, overflow is never an error, and "wraps around", the same or nearly the same as unsigned integers. "Wrap around" being better defined as results are taken modulo 2^(bitsize(the type)). Signed and unsigned operations often generate identical code, but not always. For example add and subtract are often identical. Comparison can be identical and then use a different conditional branch. I'm just being lazy here, if I really dig into it I could remember/re-derive the rules, though I don't know the instructions sets. (on 6502, the compare instruction only works for unsigned, you have to subtract and destroy a register, of which there are only three, though another point of view considers memory, or certain memory, as registers, yes I know that sounds plain wrong, but when all you have is a,x,y and single byte addresses have more features (addressing modes) than larger addresses...).<BR>
<BR>
- Jay<BR><br /><hr />Shed those extra pounds with MSN and The Biggest Loser! <a href='http://biggestloser.msn.com/' target='_new'>Learn more.</a></body>
</html>