-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CFE_SB_GetLastSenderId() returns a pointer to a shared data location #745
Comments
Use case is to disregard messages from applications that are not "allowed" to send you commands or telemetry. Example, science app can not send GN&C app a command to turn on/off the thrusters. Yes, returning a ptr to the global is insecure. That area should be protected. Option 2 would be my preferred approach as the comparison logic is in the applications domain. SB does not have to lock the area while doing the search across a potentially long list. |
I prefer the API return (via an "out" ptr parameter) the AppId of the app. If the caller needs to know the name, there should be a separate call to crosswalk the ID to a name. |
Note that my proposed solution requires first changing the CFE_SB_SenderId_t type to include |
Also note that the documentation of the API in cfe_sb.h describe the return value as the AppId when, if you look at the code, it returns a CFE status code (like CFE_SUCCESS). What a mess. :D |
…pp id of the last sender
Is your feature request related to a problem? Please describe.
CFE_SB_GetLastSenderId() in cfe_sb_api.c returns a pointer to shared data location which is risky. The function description also warns of some unpredictable or at least inconsistent behavior.
Describe the solution you'd like
I think the use cases for this function should be identified and a safer & behaviorally consistent implementation should be implemented.
Are the use cases?
A couple of options are
Additional context
n/a
Requester Info
David McComas, NASA Emeritus
The text was updated successfully, but these errors were encountered: