Re: Algorithm for Structurizing

tleylan@aloha.com
Wed, 14 Dec 1994 01:15:25 GMT

          From comp.compilers

Related articles
Algorithm for Structurizing jlapp@nova.umd.edu (1994-12-04)
Re: Algorithm for Structurizing donawa@bnr.ca (chris (c.d.) donawa) (1994-12-09)
Re: Algorithm for Structurizing kik@zia.cray.com (1994-12-05)
Re: Algorithm for Structurizing danhicks@aol.com (1994-12-06)
Re: Algorithm for Structurizing tleylan@aloha.com (1994-12-07)
Re: Algorithm for Structurizing tleylan@aloha.com (1994-12-11)
Re: Algorithm for Structurizing tleylan@aloha.com (1994-12-13)
Re: Algorithm for Structurizing tleylan@aloha.com (1994-12-14)
| List of all articles for this month |
Newsgroups: comp.compilers,comp.lang.c,comp.programming
From: tleylan@aloha.com
Keywords: analysis, design, comment
Organization: Flex Information Network HAWAII
References: <9412102334.AA21441@bcrks282.bnr.ca> <199412140056.TAA26630@nova.umd.edu>
Date: Wed, 14 Dec 1994 01:15:25 GMT

On Tue, 13 Dec 1994, Joe Lapp wrote:


> Just a little note: These two code fragments may not be equivalent...


Joe: I think that is my point. If they _are_ equivalent there is no way
for an automated system to determine that. The premise is one of turning
"bad code" into good code so the assumption should be that needless loops
will exist.


Lengthy code snippets will be used where a mathematical calculation could
substitute and of course the opposite will be true, lots of code will be
missing making routines unsafe. The automaton can't see this either.


On another newsgroup somebody posted some code that would fail if called
within a few minutes before midnight (it referenced the clock and added a
constant number of ticks to it).


I don't want to appear to be against automated systems for checking code
but I think the reality is that it is more likely to be able to reliably
cope with 2% of the problems afflicting commercial-level code not 98%.


If it is 100 hour job and it saves 2 hours it becomes academic and if it
is a huge undertaking there is every reason to believe (to me) that the
automated fixer could introduce problems where bad (but working code)
existed before.


Again I have no experience with such tools so I could be all wet but I
fix code all the time. I notice mostly "gross" errors, fundamental parts
of the system that are ill-conceived from the get go. Not much that an
automated program can sink its teeth into and even if it could it would
not have fixed much.


tom
[It is my impression that such tools can be useful to help you untangle
heavily patched spaghetti code enough that you can tell what it was supposed
to be doing before you rewrite it. -John]
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.