On Fri, Sep 22, 2000 at 08:21:57AM -0500, Jeff Foster wrote:
>
> I was looking at the conversation issue and found a bunch of c
> code in the ncp2222.h file. I know this is legal in c, but I
> consider it to be bad coding style. It there a reason for
> having this code in the .h file?
When I was writing the python code that produces C code, I realized
I needed a few C helper routines, but I did not want to put them
in the python code as strings to be printed out to the resulting
generated C file, because that would be hard to maintain and debug.
I could have put them in a separate C file, but I saw that a lot
of the symbols which could be static in a normal dissector would
have to be non-static, because the two files, the separate C file
and the generated C file, need each others symbols. Look at
packet-ncp2222.c, the generated C file. All those tables, value_strings
and ptvc_records, etc., would have to be non-static.
In order to keep the routines and all the data tables in the static,
I came up with the idea of putting the few C routines I needed in
an #included file.
What do you think? Which is cleaner?
1. Moving the C code into a separate compilation unit and making
all the data tables in the generated C non-static.
2. Keeping the symbols static by using #included source code and
putting in a comment to better explain this hack?
3. Moving the C code into the python script as strings and putting it
in the generated C file.
If people want it another way (that is, other than the current
way, which is #2), I'll change it. In the end it matters little to me.
--gilbert