Integrations (PTC products, 3rd party products and code) > Code integration (Ada, ARINC 653, C, C#, C++, IDL, Java, SQL and VB) > C Code > Reverse engineering legacy C code > Overview of reverse engineering legacy C code (C code) > Overview of reverse engineering legacy C code (C code)
  
Overview of reverse engineering legacy C code (C code)
C Code Reverser (Reverser) is designed to reverse engineer legacy C code into a model.
The Reverser allows you to reverse engineer compilable C code to a model, which you may want to do for the following reasons:
To view the structure of the C code in Modeler.
To develop the C code further in Modeler before regenerating the code.
To move the C code to another platform, such as C++ or Java.
To reuse all or part of the C code in other models.
* 
The C Code Reverser is not designed to round-trip code that is generated through ACS.
For information about the best strategy for reverse engineering C code, click here Strategy for reverse engineering legacy C code (C code)
To use C Code Reverser, you require an ACS license, a Modeler license and an ACS Language Pack for C license.
* 
The time taken to reverse engineer code will be reduced if you have write access to the Model and each Package in that Model, and in each case the Model or Package is not protected.
Parsing Code Files
The Reverser parses the files you select for reverse engineering. You should ensure that your code files compile cleanly. To parse code files correctly, the Reverser requires the following information:
#Defines that are defined in the compiler project configuration.
Compiler search paths to search for #include files.
* 
If you have code that causes Reverser parsing errors but is valid for your compiler, you can hide that code from the Reverser parser through the RTS_SYNC_INVOKED #define. RTS_SYNC_INVOKED is automatically defined when the Reverser is running, so you can make the code that causes parsing errors conditional using #ifndef RTS_SYNC_INVOKED so that the Reverser ignores it.
When you specify a search path for a #include file, you can optionally map the folder to a Package in the Model. If a #include file is found in a search path outside of the root folder, the #include file is reverse engineered only if the search path is mapped to a Package in the Model.
* 
If you add files for reverse engineering through their dsp, vcproj or batch file (created through your make utility) for your project, the Reverser populates the #Define and #Include lists from the dsp, vcproj or batch file. If possible, use the dsp or vcproj file.
Function Bodies
The Reverse Engineer Code Bodies check box (Reverse Engineering Options 1 page) determines whether function body code is reverse engineered:
If the Reverse Engineer Code Bodies check box is cleared, the Reverser does not update the Operation Body properties in the Model.
If the Reverse Engineer Code Bodies check box is selected, the Reverser updates the Operation Body properties with associated function body code. Note that blank function body code will result in the associated Operation's Body property being made blank.
When updating Operation Body properties, the Reverser attempts to preserve model object references.
Name Clashes
When the Reverser reverse engineers code, the name of each Modeler item is set to that of the reverse engineered element. If you have code elements whose names differ only by the case of the characters, this can result in a name clash in Modeler.
When there is a name clash, the Reverser uses the CODE_GENERATION_NAME property (appears on the Text tab of an item's Property Pages) to record the correct name of the code element. . Note that if a Modeler item has a CODE_GENERATION_NAME value set, ACS generates that value as the code element name.
The following example demonstrates how code elements with name clashes are reverse engineered. A struct has three attributes named salary, Salary and SALARY:
struct Class1
{
int salary;
int Salary;
int SALARY;
};
For salary, the Reverser creates an Attribute named salary - no value is set for the CODE_GENERATION_NAME property.
For Salary, there is a name clash so the Reverser creates an Attribute named Salary;1 - its CODE_GENERATION_NAME property is set to Salary
For SALARY, there is again a name clash so the Reverser creates an Attribute named SALARY;2 - its CODE_GENERATION_NAME property is set to SALARY
When the Class is generated, the three Attributes are generated with the correct names.
Basic types
The C Profile package contains the following Basic Types in the C Basic Types package: char, double, float, int, long, short, unsigned.
When you reverse code that uses a basic type, the Reverser searches the model for a matching Basic Type to use. If the Reverser cannot find a Basic Type to use in the model, it creates a new Basic Type that is scoped directly to the model. You can move any new Basic Types to the C Basic Types folder in the C Profile package.
Creating class diagrams for reverse engineered packages and classes
After reverse engineering C code, you can create Class Diagrams to show views of the items you have created in the Model.
You can create a Class Diagram and add items to that diagram by dragging those items to the diagram. Alternatively, you can add items to the diagram through the populate commands: right-click the diagram background, point to Populate, and then click the command for the item types you want to add.
Command Line Interface
The Reverser has a command line interface that allows you to reverse engineer code through a batch file. This is useful when working with a large model, because you can schedule a batch file to reverse engineer code over night. For more information, click here Command line interface (C code).