5 ms·

They may be referring to xmalloc(3). What you said is true however they are transitioning to a C++ compiler so your complaint is off-base.

• masklinn 4y ago
  > however they are transitioning to a C++ compiler OP says they want to transition to a C++ compiler but it's not clear why, the very first issue is not actually one. As GP notes, you don't need to cast out of malloc and you need a macro even less.
  • quietbritishjim 4y ago
    When the article says that implicit conversations from void* "shouldn’t be necessary" they seem to mean they feel that, philosophically, it ought not to be necessary. Certainly it doesn't protect against obvious compile time mistakes, which ought to be the point of a type system: /* Compiles in C */ int* x = malloc((sizeof)short) // Does not compile in C++ int* x = new short
    • ginko 4y ago
      I mean sure, but that seems like a minor thing compared to the codebase passing around void*'s left and right. OP could have tackled that first while sticking with C. I've had a brief look over the goaccess source code. It's 37kloc of pretty average looking C. If you think that's even close to the most complicated software projects written in C then I don't know what to tell you.
      • bornfreddy 4y ago
        Link if anyone else is curious (and lazy) : https://github.com/allinurl/goaccess https://github.com/allinurl/goaccess EDIT: looked at the code... I don't see void* being passed around, data types are used, no excessive #ifdefs, it looks like a pretty clean C app to be honest. Maybe the problem is that OP is used to C++? (as the advice to use a special struct for strings would indicate) Either way, goaccess project looks awesome.
• mananaysiempre 4y ago
  What are the typing-related issues xmalloc has that plain malloc doesn’t? As far as I can see, they’re equivalent in that respect.