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
_______________________________________________
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
