5 ms·

code sample + name (and already dealing with SIMD alignment issues) told me what the problem is. Pointer casts are ALWAYS bad in C. Try to avoid them. Reply an

code sample + name (and already dealing with SIMD alignment issues) told me what the problem is. Pointer casts are ALWAYS bad in C. Try to avoid them. Reply and down vote you old hat C programmers who will defend this. Your old practices are actively harmful to people learning the language.

rightbyte 8y ago
How do you prefer to use e.g. malloc?
- icedchai 8y ago
  You don't need to cast there... malloc returns a void*.
  - AnimalMuppet 8y ago
    Which you are going to use how? Don't you have to cast it to something to be able to use it?
    - deathanatos 8y ago
      No, you don't. The following, int *i = malloc(sizeof(int)); is valid C, and will compile just fine. I think it's considered good form, too, as the cast doesn't really add anything not already present, and might even drift out of date with the surrounding code. (And just gets in the way of legibility.) IIRC, it is not valid C++. But malloc()/void * is somewhat rarer to find there, as you have better options.
      - shakna 8y ago
        That's an implicit cast from void * to int * . void *malloc(size_t size);
        caf 8y ago
        There's no such thing as an "implicit cast". A cast is an explicit conversion (a cast expression), and the assignment expression discussed here has an implicit conversion.
        tedunangst 8y ago
        In standard parlance, that is a conversion. Only (this) is a cast.
- valarauca1 8y ago
  you mean `mmap`? Also yes I'm radical enough to suggest the 50+ year old C standard library API is bad. Which isn't really a radical position >.>
  - shakna 8y ago
    Is your irritation aimed at the implementations of malloc in the standard compilers? Or all malloc implementations? (e.g. Hoard [0]). [0] https://github.com/emeryberger/Hoard https://github.com/emeryberger/Hoard
    - valarauca1 8y ago
      my irritation is C's primitive type system. And programmers willingness to conflate their standard library with system level operations.
  - deathanatos 8y ago
    mmap and malloc do very different things. You didn't really clarify why you thought malloc() was bad, or why you think someone should call mmap(), so I'm mostly left to guess. mmap, for example, is free to require that the requested range be a multiple of a page; trying to use it as if it were malloc() would, on such systems, cause any allocations less than a page to require a whole page. And since this is a rather common case, you'd be using a ton more memory. malloc(), however, can subdivide a large allocation from the OS into small allocations for the process; it is my understanding that most modern malloc()s will do this, in some form. (It is also my understanding that some malloc() implementations will use mmap() for allocating memory from the OS…)
    - valarauca1 8y ago
      `malloc` is part of the standard library. the underlying implementation is environmental specific, or implementation specific depending on the host application. Generally speaking `mmap` is the system call that * Allocates memory * Moves allocations around `malloc` is the common entry point into a library that attempts to ensure you invoke the `mmap` system call as little as possible. trying to use it as if it were malloc() would, on such systems, cause any allocations less than a page to require a whole page. And since this is a rather common case, you'd be using a ton more memory. This is a misconception [1]. Malloc is governed by hardware limitations. If you ask for 50bytes, it'll give you a full 4KiB page, because hardware can only segment memory in 4KiB chunks. Actually some allocators will attempt to _use_ those non-allocated regions of the remaining ~4046 bytes for other allocations in order to be faster (less systemcalls), this is why sometimes writing past buffer ends can give you garbage data instead of segfaults. [1] https://stackoverflow.com/questions/45458732/how-are-memory-allocations-smaller-than-page-size-handled-in-linux https://stackoverflow.com/questions/45458732/how-are-memory-...
- unwind 8y ago
  Please see https://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc https://stackoverflow.com/questions/605845/do-i-cast-the-res... for some thoughts on this. In short (as already stated, of course), you don't need to cast void * in C to/from other object pointers. Adding a cast to the return value of malloc() is a bad idea (I'm biased).
saagarjha 8y ago
> Pointer casts are ALWAYS bad in C. Nope. There's a reason that void * exists. How would you write a "generic" function like qsort without a pointer cast?
- caf 8y ago
  You don't actually need a cast to write a qsort comparison function, because void * is implicitly converted to and from other pointer types in C. Eg: int compare_xyzzy(const void *a, const void *b) { const struct xyzzy *sa = a; const struct xyzzy *sb = b; return (sa->i > sb->i) - (sa->i < sb->i); } On the other hand, pointer casts are needed if you want to write a function like strchr() (where you can pass a const-qualified pointer, but want to return an unqualified pointer for the case where an unqualified pointer was passed).
  - saagarjha 8y ago
    D'oh! You're right, of course.
- v_lisivka 8y ago
  If you want to write "generic" function in C, use #define to generate static function for your specific type. But it much much better to use C++ or Rust instead. Example: https://svnweb.freebsd.org/base/head/sys/sys/tree.h?revision=326256&view=markup https://svnweb.freebsd.org/base/head/sys/sys/tree.h?revision...
userbinator 8y ago
Your old practices are actively harmful to people learning the language. If anything it's the insanity of standards-lawyering antagonistic compiler-writers which is "actively harmful". No one wants things like integer overflow checks being silently removed, yet there's an apparent surplus of people whose only reaction is to worship The Holy Standard and laugh at you for trying to use the language in the straightforward portable-assembler way that it was originally designed for.
- saagarjha 8y ago
  > trying to use the language in the straightforward portable-assembler way that it was originally designed for Just because it was designed that way doesn't mean that's the way it works now. There are reasons why pointer casts are left undefined (as opposed to many other sources of undefined behavior, to which I heartily agree should have been left implementation-defined).

rightbyte 8y ago

How do you prefer to use e.g. malloc?

icedchai 8y ago
You don't need to cast there... malloc returns a void*.
- AnimalMuppet 8y ago
  Which you are going to use how? Don't you have to cast it to something to be able to use it?
  - deathanatos 8y ago
    No, you don't. The following, int *i = malloc(sizeof(int)); is valid C, and will compile just fine. I think it's considered good form, too, as the cast doesn't really add anything not already present, and might even drift out of date with the surrounding code. (And just gets in the way of legibility.) IIRC, it is not valid C++. But malloc()/void * is somewhat rarer to find there, as you have better options.
    - shakna 8y ago
      That's an implicit cast from void * to int * . void *malloc(size_t size);
      - caf 8y ago
        There's no such thing as an "implicit cast". A cast is an explicit conversion (a cast expression), and the assignment expression discussed here has an implicit conversion.
      - tedunangst 8y ago
        In standard parlance, that is a conversion. Only (this) is a cast.
valarauca1 8y ago
you mean `mmap`? Also yes I'm radical enough to suggest the 50+ year old C standard library API is bad. Which isn't really a radical position >.>
- shakna 8y ago
  Is your irritation aimed at the implementations of malloc in the standard compilers? Or all malloc implementations? (e.g. Hoard [0]). [0] https://github.com/emeryberger/Hoard https://github.com/emeryberger/Hoard
  - valarauca1 8y ago
    my irritation is C's primitive type system. And programmers willingness to conflate their standard library with system level operations.
- deathanatos 8y ago
  mmap and malloc do very different things. You didn't really clarify why you thought malloc() was bad, or why you think someone should call mmap(), so I'm mostly left to guess. mmap, for example, is free to require that the requested range be a multiple of a page; trying to use it as if it were malloc() would, on such systems, cause any allocations less than a page to require a whole page. And since this is a rather common case, you'd be using a ton more memory. malloc(), however, can subdivide a large allocation from the OS into small allocations for the process; it is my understanding that most modern malloc()s will do this, in some form. (It is also my understanding that some malloc() implementations will use mmap() for allocating memory from the OS…)
  - valarauca1 8y ago
    `malloc` is part of the standard library. the underlying implementation is environmental specific, or implementation specific depending on the host application. Generally speaking `mmap` is the system call that * Allocates memory * Moves allocations around `malloc` is the common entry point into a library that attempts to ensure you invoke the `mmap` system call as little as possible. trying to use it as if it were malloc() would, on such systems, cause any allocations less than a page to require a whole page. And since this is a rather common case, you'd be using a ton more memory. This is a misconception [1]. Malloc is governed by hardware limitations. If you ask for 50bytes, it'll give you a full 4KiB page, because hardware can only segment memory in 4KiB chunks. Actually some allocators will attempt to _use_ those non-allocated regions of the remaining ~4046 bytes for other allocations in order to be faster (less systemcalls), this is why sometimes writing past buffer ends can give you garbage data instead of segfaults. [1] https://stackoverflow.com/questions/45458732/how-are-memory-allocations-smaller-than-page-size-handled-in-linux https://stackoverflow.com/questions/45458732/how-are-memory-...
unwind 8y ago
Please see https://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc https://stackoverflow.com/questions/605845/do-i-cast-the-res... for some thoughts on this. In short (as already stated, of course), you don't need to cast void * in C to/from other object pointers. Adding a cast to the return value of malloc() is a bad idea (I'm biased).

saagarjha 8y ago

> Pointer casts are ALWAYS bad in C. Nope. There's a reason that void * exists. How would you write a "generic" function like qsort without a pointer cast?

caf 8y ago
You don't actually need a cast to write a qsort comparison function, because void * is implicitly converted to and from other pointer types in C. Eg: int compare_xyzzy(const void *a, const void *b) { const struct xyzzy *sa = a; const struct xyzzy *sb = b; return (sa->i > sb->i) - (sa->i < sb->i); } On the other hand, pointer casts are needed if you want to write a function like strchr() (where you can pass a const-qualified pointer, but want to return an unqualified pointer for the case where an unqualified pointer was passed).
- saagarjha 8y ago
  D'oh! You're right, of course.
v_lisivka 8y ago
If you want to write "generic" function in C, use #define to generate static function for your specific type. But it much much better to use C++ or Rust instead. Example: https://svnweb.freebsd.org/base/head/sys/sys/tree.h?revision=326256&view=markup https://svnweb.freebsd.org/base/head/sys/sys/tree.h?revision...

userbinator 8y ago

Your old practices are actively harmful to people learning the language. If anything it's the insanity of standards-lawyering antagonistic compiler-writers which is "actively harmful". No one wants things like integer overflow checks being silently removed, yet there's an apparent surplus of people whose only reaction is to worship The Holy Standard and laugh at you for trying to use the language in the straightforward portable-assembler way that it was originally designed for.

saagarjha 8y ago
> trying to use the language in the straightforward portable-assembler way that it was originally designed for Just because it was designed that way doesn't mean that's the way it works now. There are reasons why pointer casts are left undefined (as opposed to many other sources of undefined behavior, to which I heartily agree should have been left implementation-defined).