4 ms·

But the conversion of the result of a malloc call is neither surprising nor unwanted. There's also no ambiguity. You've already explicitly defined the variable

But the conversion of the result of a malloc call is neither surprising nor unwanted. There's also no ambiguity. You've already explicitly defined the variable's type at that point.

MaxBarraclough 6y ago
There's very little harm in making the conversion explicit. It's more verbose, but it's also more explicit, which is a good thing. There is harm in implicit conversions catching the programmer unawares. This is a fairly significant cause of bugs in C code, and it's why C++ uses stricter rules, requiring you to always make these conversions explicit, even when using malloc.
- steveklabnik 6y ago
  There is a significant group of folks that believe it is actively bad. I don't write enough C these days to have a stance, personally, but https://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc https://stackoverflow.com/questions/605845/do-i-cast-the-res...
  - deleted 6y ago
    [deleted]
  - ncmncm 6y ago
    There is a significant group who are wrong about literally anything one can think of. How vocal they are about it does not correlate with much.
    - ByteJockey 6y ago
      But that fact does not get us any further towards figuring out who is wrong. It merely tells us that people disagree.
      - ncmncm 6y ago
        People still coding C can usually be counted on to be wrong.
- ByteJockey 6y ago
  You're not entirely wrong, but in the context of the specific example given (malloc), it's about as implicit as c++'s auto keyword, it just obscures type information on the right side instead of the left side of the assignment from the programmer. I would also argue that there's a hard to quantify harm in making code more verbose. More visual noise makes it harder to parse what's going on. Sure, one redundant cast isn't going to kill you. But many sources of repetition across an entire code base eventually turn it into a slog where the parts you want are obscured by useless noise.

But the conversion of the result of a malloc call is neither surprising nor unwanted. There's also no ambiguity. You've already explicitly defined the variable's type at that point.

MaxBarraclough 6y ago

There's very little harm in making the conversion explicit. It's more verbose, but it's also more explicit, which is a good thing. There is harm in implicit conversions catching the programmer unawares. This is a fairly significant cause of bugs in C code, and it's why C++ uses stricter rules, requiring you to always make these conversions explicit, even when using malloc.

steveklabnik 6y ago
There is a significant group of folks that believe it is actively bad. I don't write enough C these days to have a stance, personally, but https://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc https://stackoverflow.com/questions/605845/do-i-cast-the-res...
- deleted 6y ago
  [deleted]
- ncmncm 6y ago
  There is a significant group who are wrong about literally anything one can think of. How vocal they are about it does not correlate with much.
  - ByteJockey 6y ago
    But that fact does not get us any further towards figuring out who is wrong. It merely tells us that people disagree.
    - ncmncm 6y ago
      People still coding C can usually be counted on to be wrong.
ByteJockey 6y ago
You're not entirely wrong, but in the context of the specific example given (malloc), it's about as implicit as c++'s auto keyword, it just obscures type information on the right side instead of the left side of the assignment from the programmer. I would also argue that there's a hard to quantify harm in making code more verbose. More visual noise makes it harder to parse what's going on. Sure, one redundant cast isn't going to kill you. But many sources of repetition across an entire code base eventually turn it into a slog where the parts you want are obscured by useless noise.