Comments by "MrAbrazildo" (@MrAbrazildo) on "your software is too fuzzy" video.

  1. I disagree, because: a) -1 in unsigned means all bits ON, which still can be represented. Example: C++ uses string::npos as -1 unsigned, to represent a failed algorithm attempt. It'd be bad design only if you were 100% sure that -1 should be a valid value. b) signed is much faster. So, to use unsigned everywhere, at least make a macro for its type, to be used on debugging compilations only.
    2
  2. 1:27, you could get rid of that label and its goto, by changing this to else. Nowadays, C can get rid of resources automatically. Why didn't you use it? 2:00, if you want to use dangerous literal numbers, at least create a global constant: 0x_4545. a) If a typo occurs, compile error. b) If that number ever changes, you can detect all of its occurrences by the compiler, not needing to rely on code editor features. Another thing: all sorts of fields are being accessed in what be was a 'char *'. If that recv function (1:10) failed to fill 'databuf', all sorts of runtime errors would occur. Could recv fail? 2:30, no check for h->len, huh? Hm, I know to where this is going to... 7:10, yep, I knew it. However, I would write this as: memcpy (msgbuf, data, h->len > 64 ? 64 : h->len); //At least it would get what could fit in it. Whenever I mistake something like this, I write my own f(), like memcpychk, which would compare size of both arrays forever (at least if NDEBUG wasn't #defined). C++ provides additional security, by allowing to give same names. So it'd require namespace specification: ::memcpy for C's or my_own_namespace::memcpy for yours.
    1