-
Notifications
You must be signed in to change notification settings - Fork 27
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
Potential Truncation of Number of Open Files #27
Comments
Switched to enhancement since this is informational and only in the HK packet (not the get open files command response telemetry) and basically just means we only support reporting up to uint8 files in HK. Note the OSAL_CONFIG_MAX_NUM_OPEN_FILES parameter which is used to set OS_MAX_NUM_OPEN_FILES limits within OSAL the max number of open files which is currently defaulted to 50. First off the tlm packet does support uint32: Lines 398 to 404 in 3a8d00a
OSAL has a config param defaulted to 50 for the maximum number of open files: Logic for the command all supports uint32: Lines 582 to 611 in 3a8d00a
Really the issue is in the HK packet (not the command response telemetry): Line 448 in 3a8d00a
Line 422 in 3a8d00a
|
Agreed - that is what I was trying to communicate. Thanks for the clarification! |
The number of open files is treated as a uint32 by FSW, but is telemetered as a uint8 such that truncation may result if the number of open files allowed by OSAL grows.
The text was updated successfully, but these errors were encountered: