5 ms·

> I agree entirely with the author on the limitations of Raylib. Wow this is kind of insane. About this > Raylib doesn’t do basic parameter validation, by des

• kragen 3y ago
  in c and c++ this is not just normal but almost unavoidable. if your function takes a t* and someone casts a random int to a t* and pass it in, it is gonna segfault. no possible way to validate it, though in theory you could open /proc/self/maps and iterate through it to catch the segfault cases, or install a segfault handler
  • lelanthran 3y ago
    > if your function takes a t* and someone casts a random int to a t* and pass it in, it is gonna segfault. 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); I expected that a function that returns an array needs to tell the caller how large that array is. This specific function is not one I would complain about. These things are usually documented in the headers. In this case it says: // Load file data as byte array (read) So, yeah, it's pretty clear to me that the number of bytes has to be returned somewhere, and there's only one parameter called `dataSize`, so this isn't something I consider to be a valid complaint. [EDIT: Escaped pointers, and added last paragraph]
    • defrost 3y ago
      > unsigned char WARNING unpaired | unescaped *'s !! :-) grrr, markup
      • lelanthran 3y ago
        Thanks, fixed.
    • naasking 3y ago
      > Sometime, however, you just need to be familiar with enough projects in C that common-sense gets built. 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.
      • lelanthran 3y ago
        My point is not that it was good or acceptable, my point is that, while not perfect, it isn't bad enough to warrant the moniker of `insane`.
    • kragen 3y ago
      yeah. unlike an arbitrary garbage pointer, a null pointer is something the callee could detect. but on linux or windows the operating system will reliably detect it for you, and in a way that makes it a lot easier to debug: it segfaults, making it obvious that there's a bug, and your debugger will show you the stack trace leading up to the LoadFileData call with the null pointer parameter. and, as you point out in your other comment, in the very next line after your call to LoadFileData, you need the data size, and if you passed in a statically null pointer, you don't have it, so you realize you're going to need to pass in a pointer to an actual int 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
  • pjmlp 3y ago
    Even that isn't fullproof. Microsoft has deprecated all pointer validation functions on Windows, because there were plenty of corner cases regarding pointer validation.
    • kragen 3y ago
      aha, thanks. yeah obviously /proc/self/maps won't help much there
• lelanthran 3y ago
  I think the word 'insane' is going to far to describe the behaviour of the specified function. 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.
  • uecker 3y ago
    Arrays in C have length information. Pointers do not.
    • lelanthran 3y ago
      > Arrays in C have length information. Pointers do not. Sure, but they don't carry that length information when being returned from a function.
    • SJC_Hacker 3y ago
      > Arrays in C have length information. 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.
      • jstimpfle 3y ago
        Not every pointer works with free(). Most don't.
      • deleted 2y ago
        [deleted]
    • 3y ago