lclint-interest message 26

Date: 08 Feb 95 17:02:35 EST
From: "JR (John Rogers)" <72634.2402@compuserve.com>
To: "INTERNET:evans@cs.virginia.edu" 
Cc: LCLint interest list ,
        John Gerard Malecki 
Subject: LCLint initialization vs. sequence checking

Hi all!  Back in November, there was some discussion on this email list
about whether it was useful to check for certain required sequences of
operations (as opposed to a single initialization).  I think that being
able to check module initialization/deinitialization is good; the same
goes for object initialization/deinitialization.  Dave
(evans@cs.virginia.edu) was wondering if anything more complicated is
useful:

> Olender and Osterweil ("Interprocedural Static Analysis of Sequencing
> Constraints", ACM Transactions on Software Engineering and Methodology,
> Jan 1992) have done some work on allowing programmers to specify more
> general sequencing constraints using regular expressions and detecting
> violations of the constraints statically.  From my own experience, I
> think it is very unusal to have code which depends on sequencing
> constraints other than initialization before use.  
>
> Does anyone have any conflicting experience suggesting more general
> sequencing constraints are useful in real programs?

Since you asked, I just thought of a situation where sequencing contraints
might be nice.  This example is second-hand and perhaps decades out of
date, but it will give you the general idea.  I don't consider this a
good design, either.  My understanding is that in FORTRAN, after doing
an open of a file, the "seek" location is undefined or implementation
dependent.  Thus, an application would have to "open" and then "seek",
presumably via calls to 2 different routines.

Perhaps someone could handle this particular requirement by having two
nested objects, each with a init/deinit required checks.

I'm not asking you to implement checks for this sequence checking.  But
I thought I'd pass along this example so you could make that decision.

Happy hacking!
--JR (John Rogers)