Is your feature request related to a problem? Please describe.
For historical/backward compatibility reasons, the API of these two functions doesn't follow the typical flow. Rather than providing a uint32 ID output buffer as the first argument with a separate int32 return code, they return the OSAL ID cast as an int32 on success. For these functions, the caller is expected to check if the result is negative, and if so, consider it an error code. Whereas if it is non-negative, the caller is expected to cast it back to a uint32 type and interpret it as an OSAL ID.

Describe the solution you'd like
These should be like all other OSAL APIs and pass back the ID separately from the return/error status.

Describe alternatives you've considered
Leave as is. But these two functions present a challenge when making a distinct type for OSAL IDs .

Additional context
In the current implementation,. these are just compatibility wrappers anyway. They both call OS_OpenCreate() internally, which provides both open (existing file) and creat (new file) based on the flags it was passed. The OS_OpenCreate function does follow the correct pattern so one option would be to just expose this to the public API.

The other option is to create a new version of OS_open and OS_creat which follow the correct pattern. But in order to provide a transition they would have to use different names.

Requester Info
Joseph Hickey, Vantage Systems, Inc.