search

riebl / vanetza

Open-source implementation of the ETSI C-ITS protocol stack
Other
202 stars 158 forks source link

Identical Header Guards Cause Resolve Errors #214

Closed buraksenkus closed 1 month ago

buraksenkus commented 9 months ago

asn1/its/Latitude.h, asn1/pki/Latitude.h and asn1/security/Latitude.h files have identical header guards as _Latitude_H_. This causes compile error when more than one of these files are included directly or transitively and one of the data field is tried to be used.

An example case is shown in below figure. As you can see, Latitude_unavailable enum defined in its/Latitude.h cannot be resolved if it is included after other Latitude.h files. Same situation applies for Longitude.h files as well. But there is no error since I didn't include other ones before that.

image

Reordering includes fixes the usage of *_unavailable enums and there might be no such "direct multi-include" situation in most of the time. But this issue is likely to happen "transitively" when trying to implement some security cases.

Additionally, this issue might exist in other data types which has same names. Unfortunately, I didn't have more time to check but this must be considered as well.

I think, the issue is related to asn1c's header guard creation method. From my point of view, making asn1c to append a random suffix to the end of header guard name should fix the problem.

I'm sorry if this issue might be created under asn1c but since the generated files are committed in this repository, it must also be fixed. Thanks in advance!

riebl commented 9 months ago

Hi @buraksenkus,

the clash of include guard names is indeed a problem which should be solved by asn1c ultimately. We may extend our patching mechanism to "uniquify" the guards, e.g. by appending a hash. For example, we could take the header's path relative to the project root, hash it, and append the last 12 hex symbols of the hash to each include guard. This should be feasible to realize in CMake and produce unique include guards.

v0-e commented 8 months ago

asn1c (mouse's fork) supports prefixing through the environment variable ASN1C_PREFIX. It adds a defined prefix in every C type associated with an ASN.1 definition, including also the header guards. Can be a possible solution, not only for this issue, but also to eventually support ITS messages of several versions.

riebl commented 1 month ago

Update: For the security sub-system I have meanwhile switched to the prefix "VanetzaSecurity" so these don't clash anymore with the generated sources from CAM/DENM/CDD in vanetza/asn1/its.

I have not yet decided on further prefixes for other message types, though. It may make sense to distinguish Release 1 and Release 2 message sets, for example. I close this ticket because the original issue is solved.