Wow this is kind of insane. About this
> Raylib doesn’t do basic parameter validation, by design. This function segfaults when dataSize is null: (...)
The developer answered this
> For most of the raylib functions is up to the user to validate the inputs, if raylib should consider all possible bad-use scenarios it would require reviewing most of the library functions and it will increase source-code complexity.
It returns an array of bytes. If you, the programmer, wrote a line that called that function, on the very next line you are going to try to use the array, realise that you don't know the length, and realise that the `NULL` that passed in on the line above is probably the output for the length!
In order to actually write a call with `NULL` for the dataSize argument, the programmer needs to be clueless about how to write a for loop.
So, no, I can't easily see a situation where a programmer accidentally uses a `dataSize` parameter of `NULL`, because that would mean they don't know that arrays in C have no length information, which is C 101.
Sure, but they don't carry that length information when being returned from a function.
Not in any sense that is actually useful to the programmer, at runtime at least. You cannot ask an array how big it is.
Pointers actually do have length information as well, otherwise free() would not work. But its the same deal with arrays - there is no way to access it outside of compile time constants, if those are even present.
This is 100% correct. The parent of the parent is confused (or is just using terminology incorrectly) as are the current siblings to my comment.
One post claims pointers carry length information so that free works. This has nothing to do with pointers, it has to do with the implementation of malloc and friends. It's only a promise of a successful malloc that you can free, nothing to do with the pointer other than it was returned by malloc. Pointers can point to all sorts of things, the only information they intrinsically have are the type of the object they point to and its address.
Two posts claim a function can return an array of bytes. This is impossible in C. You can't return an array of bytes. You can return a pointer that might point into a continuous sequence of bytes. You could also return a struct whose member is an array, but that's rarely done. When you return (or pass) what looks like an array syntactically, it is converted to a pointer to its first element.
Arrays, on the other hand, always carry length information via the sizeof operator. A special hand waving case would be you could define a pointer to an array (not a pointer to the first element of an array), so in effect the length is contained within the pointer type. E.g. char (*foo)[42] declared foo as a pointer to an array of char with length 42.
So that is pretty much worthless outside the current scope where they were declared.
True, that is not something a function ought to defend against.
However, the complaint was not about that, though, it was about not checking if the dataSize parameter is NULL.
I don't really have a problem with functions that segfault when given NULL pointer parameters as long as this is clearly documented!
Sometime, however, you just need to be familiar with enough projects in C that common-sense gets built. In the specified example:
unsigned char *LoadFileData(const char *fileName, int *dataSize);
These things are usually documented in the headers. In this case it says:
// Load file data as byte array (read)
[EDIT: Escaped pointers, and added last paragraph]
WARNING unpaired | unescaped *'s !! :-)
grrr, markup
And if every C project takes this same philosophy to poor documentation, how exactly is a new person learning C supposed to build that common sense? Brushing off poor documentation with "you just need more experience" is not a valid response. The documentation for that function could be much more clearer without being much longer.
so, while the documentation could and should be more explicit than the single telegraphic line you quote, the function's behavior is fine, and detecting and trying to handle the null pointer would make its behavior worse and harder to debug (except on like an arduino or ms-dos or something)
not every c api description needs to be an introductory tutorial for c
Microsoft has deprecated all pointer validation functions on Windows, because there were plenty of corner cases regarding pointer validation.