[*] Concerns about safety, errors handling and inconsistencies

[raysan5]

This issue is related to a reddit post about errors handling and inconsistencies.

raylib original approach was a hard focused on simplicity, trying to avoid any extra-code that could pollute the functions, leaving the security data checks to the users and expecting the data to be provided to most functions to be valid data.

But raylib has been +11 years in development and in that time some data validation checks have been added here and there resulting in some inconsistencies... and polluting the functions code with some things I originally tried to avoid (i.e early-returns).

Still, I tried to follow some principles in the library:

• Users are the owners of data and valid data should be provided to raylib functions.
• raylib does not use assert() or exit().
• In case of issues with data, priority is logging a warning message and trying to return gracefully (with valid default data or at least something to be validated at user side - i.e. zero-initialized struct)
• raylib does not (usually) use error return codes. (But lately some were added to file-system functions)
• raylib text functions always expect \0 terminated strings, it's up to the user to make sure that happens.
• raylib does not validate memory allocations returned pointers, the chances for a failure on memory allocation are extremely low but, in any case, users can define their own allocator macros.

This issue is open to analyze if there could be some of those tentative rules not applied in some functions or if there are some inconsistencies.

[orcmid]

One probably-unhelpful comment:

When "user" is used above, the developer of a raylib-based application is meant. The problem is when that application is distributed to end-users and the application fails in a place where log messages, even if actually produced, are invisible and unknown to the casual user. It is for this situation that defensive programming is valuable.

Also, raylib-internal operations may also need to be defensively programmed, as indicated in some places already, where a problem is not protectable above the API, it being related to under-the-covers failures.

That could also apply to unchecked inputs from above that violate API pre-conditions. Perhaps the pre-conditions should be carefully explicit every and all the time.

The worry should be about defective distributed executables. That's without considering the creation or corruption of an app for malicious purposes.