CIL gives names to anonymous structure or union types, such as in the following.
typedef struct { double r; double i; } complex;
CIL will give it a name such as __anonstruct_complex_nn, where 'nn' is a number chosen serially. So, the same header defining the same struct complex will generate different 'nn' in different compilation units, because of the different inclusion contexts.
This is harmless in nearly all applications of CIL. But in my case it causes a problem, because according to the C standard, types with different tags are not compatible (section 6.2.7), whereas before the CIL transformation, they were compatible. It's important for my tool that compatibility across compilation units is preserved; I therefore have to erase the 'nn' to work around this behaviour.
A better option for CIL would be to compute the nn based on a structural analysis of the definition, so that the same nn would always be generated for the "same" struct. This would not be easy to get completely right, but a "good enough" version probably isn't too hard. Consider that an offer to contribute a patch at some point!
CIL gives names to anonymous structure or union types, such as in the following.
CIL will give it a name such as __anonstruct_complex_nn, where 'nn' is a number chosen serially. So, the same header defining the same struct complex will generate different 'nn' in different compilation units, because of the different inclusion contexts.
This is harmless in nearly all applications of CIL. But in my case it causes a problem, because according to the C standard, types with different tags are not compatible (section 6.2.7), whereas before the CIL transformation, they were compatible. It's important for my tool that compatibility across compilation units is preserved; I therefore have to erase the 'nn' to work around this behaviour.
A better option for CIL would be to compute the nn based on a structural analysis of the definition, so that the same nn would always be generated for the "same" struct. This would not be easy to get completely right, but a "good enough" version probably isn't too hard. Consider that an offer to contribute a patch at some point!