Author Topic: C Code Engineering  (Read 1313 times)


  • EA User
  • **
  • Posts: 435
  • Karma: +0/-0
  • We have met the enemy, and he is us.<Pogo, 1970>
    • View Profile
C Code Engineering
« on: March 07, 2011, 11:06:27 am »
A few requests regarding reverse engineering of less-than-well-crafted C code:

1. An option should be provided to allow imported .c and .h files to be treated as entirely independent entities, even if the file names are the same. Not all real-world C modules consist of neat .h-.c file pairs. At present, it seems that EA assumes it needs to import all entities in identically named .h-.c file pairs; this doesn't always work for all code. Function prototypes for a given .c file may at times be found in the same .c file or may be in a completely unrelated (by name, at least) .h file. I've also seen .c files used as #include files. Whether or not this is good practice isn't the issue - it is the practice in some cases, good or not.

2. EA assumes that variables and functions defined only in a .c file are private, and that all such definitions in a .h file are public. Again, this isn't a valid assumption in all cases. An option should be provided to treat only external (i.e. not in a function definition) static variables and functions as private.

Fred W
Fred Woolsey
Interfleet Technology Inc.

Always be ready to laugh at yourself; that way, you beat everyone else to the punch.