[M3devel] comparisons vs. subranges

[Jay K]

Integer overflow is not a safety problem. That was the news (to me).

Subranges do need to be enforced, at certain points, for their to be safety.

This change doesn't change that.

(Compiler bugs break safety, as always.)

 

 - Jay


> Date: Sat, 13 Mar 2010 13:29:24 -0500
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] comparisons vs. subranges
> 
> On Sat, Mar 13, 2010 at 10:19:21AM +0000, Jay K wrote:
> > 
> > <*UNUSED*>PROCEDURE CardinalGE0(a:CARDINAL):BOOLEAN=BEGIN RETURN a>=0; END CardinalGE0;
> > <*UNUSED*>PROCEDURE CardinalEQN1(a:CARDINAL):BOOLEAN=BEGIN RETURN a=-1; END CardinalEQN1;
> > 
> > 
> > 
> > 
> > Seems to me, the front end should notice these.
> > 
> > The first should always be TRUE.
> > 
> > And possibly, possibly warn.
> > 
> > The second should always be FALSE.
> > 
> > And possibly, possibly warn.
> > 
> > 
> > 
> > "Generic" programming often hits this sort of thing though, a good reason not to warn.
> > 
> > Programmer might also be working with existing code and have changed INTEGER to CARDINAL.
> > 
> > Or be defending against future maintainers changing CARDINAL to INTEGER.
> 
> Wasn't there a discussion a while ago about subranges out-of-bounds not 
> being a safety problem? (Or was it arithmetic overflow?) This 
> optimisation might well cause a quite hard-to-find bug if we don't 
> guarantee subrange integrity.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100313/3f13379c/attachment-0002.html>