[314]

> It's easy to write things like this when you're at the wrong end of the Dunning-Kruger bathtub

Amusingly, only the most simplistic graphs of the Dunning-Kruger efect would portray it as matching a bathtub curve. In particular the rather slow slope of confidence rising as competence improves is dramatically (and significantly) different from the sharp drop-off of false confidence. Rather than two steep sides, there is a marked asymmetry.

I suspect that you may have misunderstood the author's point though. Even if you swap the arguments as you suggest, you still run into this problem described in the link that the author provides:

  When used on a text mode stream, if the amount of data requested (that is, size \* count)
  is greater than or equal to the internal FILE \* buffer size (by default the size is 4096 bytes,
  configurable by using setvbuf), stream data is copied directly into the user-provided buffer,
  and newline conversion is done in that buffer. Since the converted data may be shorter than the
  stream data copied into the buffer, data past buffer[return_value \* size]
  (where return_value is the return value from fread) may contain unconverted data from the file.
  For this reason, we recommend you null-terminate character data at buffer[return_value \* size]
  if the intent of the buffer is to act as a C-style string.

i.e. his complaint is that if he initialises the buffer to zeros and reads N bytes into it there is the possibility that zeros after the N bytes are overwritten.

This is distinct from the problem of not getting enough information back if you swap the argument order, and as it matches his decription in the text before the link I would assume that the swapped arguments are actually a typo rather than a misunderstanding of the API.