Move AesEax definition to aes.h#6885
Conversation
|
|
||
| /* Because of the circular dependency between AES and CMAC, we need to prevent | ||
| * inclusion of AES EAX from CMAC to avoid a recursive inclusion */ | ||
| #ifndef WOLF_CRYPT_CMAC_H |
There was a problem hiding this comment.
This works, but why not use the WC_CMAC_TYPE_DEFINED macro guard and just have "typedef struct Cmac Cmac" if not yet defined? Then include cmac.h in the source file if building with EAX enabled. We've ran into similar problems with includes and typedef's (grep for TYPE_DEFINED macros).
There was a problem hiding this comment.
wasn't aware of that strategy, let me look into it
There was a problem hiding this comment.
@JacobBarthelmeh I'm not able to get that strategy to work, given that the AesEax structure needs to hold a Cmac struct (and not a Cmac*, which would work). The compiler needs to know the size and definition of that structure when it processes the header for a given translation unit using aes.h, and so we can't get around this with a forward declaration (AFAICT). I don't believe there is anywhere in our code where we use the TYPE_DEFINED-proteced forward declaration in the manner of this specific circular dependency scenario (only for resolving pointer types, for which a fwd declaration will work). I'm made a small C program to test this out and I can't get the strategy to work with simpler structs either. If you think I'm wrong about this, please let me know how you think I can get around it, but I think the only solution (that doesn't involve me creating a new file for aes eax) is including cmac.h from aes.h like I proposed above.
3 participants
Description
Makes AesEax struct available for public use.
New PR taking over for #6864
Fixes #6862
Testing
Tested using provided reproducer. Confirmed fixed.