[Python] C source viewer/mapper?

My advice. Don't
The reason no such utillity exists is because it is damn near impossible to
create such a mapping.
The C language is a context free grammar (LR(1)) while a flow chart is a
regular grammar.
The grammars that can be expessed by a context free grammar are a superset
of the grammars that can be expessed be a regular grammar.
This means there is no general mapping from one to the other. The other way
from flow chart to C works fine.
Altso forget translating C into python.
Instead figure out what the program does.
Write a spec of behaviour and write the python program from scratch using
this.
John Thingstad

I am working on a c code parser written in python right now.
My main focus is parsing .h files to generate wrapper code for python
(yes i know about SWIG), but i hope it will do a lot more, such
as general "explaining" that you (and many others) would like.

highlighting external traffic to sockets is somewhat specific,
but my hope is that a well written python c-parser will allow for
custom extensions without to much hassle.

let me know if you're interested; i'll announce something on c.l.py
soon i hope,

cheerioh,

Simon Burton
http://arrowtheory.com

Are you doing it based on a Grammar file like Python's

D:\Python-2.2.2\Grammar\Grammar

file? Do you know if there are free grammars around that work with the Python stuff?
Some commercial flex/bison type tools advertise big lists of language grammars,
but I haven't googled for open source grammars per se. The other obvious question
is if there's an automated format conversion between the two. Flex by itself can
handle lots of conditional stuff (I defined a custom HTML parser using it which goes
pretty quick, being compiled C++ (yes, you can also use C++).

BTW what is the reference in Python's grammar in the line

# Commands for Kees Blom's railroad program

Is that like the diagrams in the old Jensen/Wirth Pascal book? I loved it that
the whole language was diagrammed on on a couple of pages.

Regards,
Bengt Richter

No, i'm writing in the style of a "recursive descent" parser;
rather than bringing the grammar to the fore, the recursive parsing
mimics the grammar in the (hand coded) control flow. Also i've heard
that these are faster parsers than the grammar based ones.
My sarting point has been Peter Van Der Linden, his book "Expert C
programming", where he explains how to parse c declarations.
I have also been working with an ANSI c grammar (for bison) i found somewhere,
it's been helpful, but the grammar allows a lot of weird stuff, like "int
f()()()();"
Some interesting points you raise,

Simon Burton
http://arrowtheory.com

Simon Burton wrote:

[snip]

I'd like to suggest that your header/interface parser generate XML that
describes the interface. If you do that, others can write processors that
transform the XML for different purposes, generate wrappers, generate
documentation, perform code analysis, etc. And, best of all, these tools
(for transformation, analysis, etc) could be written in Python. By
generating XML, you are in effect making the output of your parser public.

You may want to look at the following for inspiration:

- SWIG generates XML if you use the "-xml" option.

- http://www.mip.sdu.dk/~fonseca/idl/

Dave

That's a lie propogated by XML proponents and those wishing to claim
openness for proprietary data formats. It's equivalent to saying that
by generating ASCII, I'm in effect making the output of the parser
public.

XML - and ASCII - attach fixed meanings to various syntactic features
of the data. Knowing those features is not sufficient to understand or
process the data intelligently. You have to know the semantic meaning
of the variables in the fixed syntax before you can do that. You can't
even decide if a given bit of XML is valid output without having a
DTD.

That being said, you can get a lot of good from having parts of the
syntax fixed to a common standard. For ASCII, you get to use things
like standardized numeric<->string conversions. For XML, you get
libraries that will turn the flat XML text into structured objects,
transform the data, and even let you edit it in a user-friendly
manner. These are all good things, and make XML a good choice over a
proprietary format if all other things are equal.

<mike

The DMS Software Reengineering Toolkit can be used
to automate conversions, although this one could
be pretty hard. It can be obtained with a full
ANSI C front end having name and type resolution,
which can answer the questions of what variables
are used where. "What variables traverse blocks"
is a dataflow question, and requires pretty serious
dataflow infrastructure to answer "easily".
Alas, we aren't quite that far along, so getting
this information is possible but not fun.

I will say that starting from scratch to build
the entire infrastructure you need for processing
C might sound like fun, but it will take you
a lot more effort than you think.
[Yes, I'm biased, but that comes from way
too much experience doing this kind of thing].
This is why we offer a commercial product;
it allows us to distribute the engineering cost
across a lot of customers.

See http://www.semdesigns.com/Products/DMS/DMSToolkit.html.

--
Ira D. Baxter, Ph.D., CTO 512-250-1018
Semantic Designs, Inc. www.semdesigns.com

"Simon Burton" <simonb at webone.com.au> wrote in message
news:pan.2002.12.23.02.50.50.847704 at webone.com.au...
map
points
to
the
that
by
place,
this