You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
As a general rule of thumb, all header files should directly include whatever dependencies they require in order to provide the types/declarations they intend to provide.
However in the CFE headers there remain a couple omissions/mistakes in this regard:
cfe_es.h declares the function CFE_ES_GetModuleInfo which accepts a resource ID input, so this depends on cfe_resourceid_api_typedefs.h, but it does not directly include this dependency
cfe_tbl_api_typedefs.h defines a CFE_TBL_Info_t type, which in turn has a member sized to CFE_MISSION_MAX_PATH_LEN, which is provided by cfe_mission_cfg.h, but it does not directly include this dependency.
In both cases the current framework sample builds do compile successfully, because the dependent header gets included implicitly (i.e. by some header before it) in all the current use cases, but this could change in other use cases.
To Reproduce
Use header files in contexts beyond what the current framework does, such as 3rd party code only including "cfe_es.h" or "cfe_tbl_api_typedefs.h" directly.
Expected behavior
Headers should work (compile w/o errors or warnings) when included individually, they should include all dependencies directly rather than relying on inclusion ordering.
System observed on:
Ubuntu
Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered:
Some CFE API headers were missing dependency inclusions, where the header
was referencing a type or symbol but not directly including the header
file that provides that type/symbol.
Adding the dependent include allows the headers to work more consistently.
Describe the bug
As a general rule of thumb, all header files should directly include whatever dependencies they require in order to provide the types/declarations they intend to provide.
However in the CFE headers there remain a couple omissions/mistakes in this regard:
cfe_es.h
declares the functionCFE_ES_GetModuleInfo
which accepts a resource ID input, so this depends oncfe_resourceid_api_typedefs.h
, but it does not directly include this dependencycfe_tbl_api_typedefs.h
defines aCFE_TBL_Info_t
type, which in turn has a member sized toCFE_MISSION_MAX_PATH_LEN
, which is provided bycfe_mission_cfg.h
, but it does not directly include this dependency.In both cases the current framework sample builds do compile successfully, because the dependent header gets included implicitly (i.e. by some header before it) in all the current use cases, but this could change in other use cases.
To Reproduce
Use header files in contexts beyond what the current framework does, such as 3rd party code only including "cfe_es.h" or "cfe_tbl_api_typedefs.h" directly.
Expected behavior
Headers should work (compile w/o errors or warnings) when included individually, they should include all dependencies directly rather than relying on inclusion ordering.
System observed on:
Ubuntu
Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: