On Fri, 15 Aug 2008, lex wrote:
>
>
> On Fri, 15 Aug 2008, Phil M Perry wrote:
>
>> Since this is auto-generated, that makes it rather messy. Is it possible
>> for you
>> to insert code into it, either as part of the generation or manually
>> afterwards?
>>
>> int x_set = 0;
>>
>> at each place where x is about to be READ, insert x_read
>> at each place where x is about to be WRITTEN, insert x_write
>>
>> Define x_read to
>>
>> if (!x_set) {fprintf(stderr,"x is not yet set at line %d\n",__LINE__);}
>>
>> Define x_write to
>>
>> if (!x_set) {x_set = 1; fprintf(stderr,"x is first set at line
>> %d\n",__LINE__);}
>>
>> Something along those lines ought to work, or may give you an idea. Once
>> you
>> have it working, you can make x_read and x_write empty so they don't slow
>> you down. Good luck!
>>
>> P.S. Take whoever wrote the generator that produces this rat's nest of
>> gotos
>> and slap them upside the head!
>>
>
> Yes, and that is exactly my point. The compiler already analyzes the
> logic, and generates the msg if I have a potential problem.
>
> The trace output I mentioned has the record of what x was along the way,
> by doing reads (uses).
>
> Sets are identifiable because there is an equal sign in front of the
> variable.
>
> There are really three parts:
>
> First, I want to know if I have a potential problem.
> Second, if so, I want to know exactly which lines are part of the problem.
> Third, I want to know how it can get there and have a potential problem.
>
> I would rather be able to run some script that just tells me the answers,
> without me having to do anything to the source.
>
> If the script compiles a bunch of temporary source files as part of
> finding out, I don't care.
>
> If it adds temporary stmts to the temporary source files, I don't care.
>
> I am slowly coming around to the point of view that maybe the dataflow
> analysis is not so hard. The hardest part of such a program is to have
> a correct parser for the input language.
>
> The dataflow analysis per se is not a very hard problem, but
> it has a lot of steps.
>
> I may spend some more time considering this option before using all of the
> above.
>
> As for the program generator, it allows you to define things recursively,
> but when it finds that it already knows the answer, i.e. the particular
> invocation with all of its input conditions has already been encountered,
> it can generate a goto instead of a function call, which is a lot less
> expensive of an operation, considering that the function call will
> have to copy all of the interface variables to the stack, etc. and
> back again afterward.
>
> In this case, there are sometimes dozens of variables common to the
> recursion logic.
>
> An actual input program for the program generator does not need to have
> any gotos, nor loops, and does not really need any fors, whiles, or untils,
> although I still find them convenient sometimes.
>
> In a way, working with the output of the program generator is no different
> than working with someone else's grubby program that gets the used before
> defined msg.
>
> Someone else says to me, can you help me out? I have 40,000 lines of 30
> programs, and I'm getting this msg 150 times for 150 variables. How do I
> fix it? I mean really fix it, not just make the msg go away.
>
> In that case, I have to assume that I don't have control over how the
> program was written, I just have to fix the problem by finding the stmts
> that may cause errors, and, hopefully only those that may cause errors,
> and exactly which ones.
>
> The script should work for any C++ program, whether it has gotos or not.
>
> Lex
> _______________________________________________
I have decided to go with the run time trace for finding these problems.
A stmt such as `q("set x = %d", x); ' enters the msg in the trace file.
Then at any point in the trace file, I can find where the variable is set
by looking for "?set x =" (find prior occurrence of set x =) in the vi
editor, or the equivalent in some other editor.
Then, as you say, I can put q("use x", x); in the places where it is used.
Then the use msgs are also in the trace.
I refer to sets and uses because all of the complier writers up until
near the end of the 20th century used those terms.
The pioneering work of John Cocke and others for dataflow analysis was
called "use and definition chaining."
o set == write
o use == read
I can automate the annotation of the source code with some simple
editor macros, and then apply them to all references to a variable in
the source.
I may even add this to the program generator, so it is transparent to
the user.
The next thing I will want is a filter for the trace output that
checks for a variable used before being set.
For that, I also have to make the declaration a part of the trace,
so I will issue a msg like `q("set x = void");'
Then the filter will check for these errors without me having to do any
work at all, which was my initial goal.
Lex
_______________________________________________
Mid-Hudson Valley Linux Users Group http://mhvlug.org
http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug
Upcoming Meetings (6pm - 8pm) MHVLS Auditorium
Jun 4 - Sqeak! and eToys
Jul 2 - KVM (Tenative)
Aug 6 - Zenos
Sep 3 - TBD
