Hmm, as far as I can tell most of the pointer casts I see there are unnecessary.
- ifr_name is cast to char pointer. It's already a char array.
- A few memcpy() calls cast their arguments to void pointer. This is just silly. All pointer types implicitly convert to that. This anti-pattern can create bugs with some 64-bit compilers if you fail to declare a function prototype (implicit `int` from undeclared function, cast into `void pointer` = bad times).
- The file ends in `.c`, but the return type of `malloc` is cast to different pointer types. This is a big "author has no idea what they're doing" red flag to me. In C you can implicitly convert void pointer to any other pointer type. It's not the same as C++. This also happens to let you fall into the "convert `int` to `void pointer` trap of the previous point.
I hate it when people assume that they know everything and attempt to lecture others. Especially when you go on large platitudes like "This is a big 'author has no idea what they're doing' red flag to me." Maybe, the author is actually compiling the code with a c++ compiler?
No actually, in my experience it is a red flag, and worse, it hides really nasty bugs like the conversion from int that I mentioned.
To elaborate, I do find misuse of casts to be a reliable shibboleth to determine competence in C and C++. If a programmer writes lots of pointer casts that don't make sense, that's usually reliable a signal that the programmer doesn't really understand the warnings from their compiler and is just trying to shut up the warnings (real or perceived) rather than fix actual problems. This approximation has played out well in my experience.
It's not meant to be judgmental, I too made the same mistakes when I was learning C. I remember in 2000 or so I made the "cast memcpy args to void pointer" mistake because the manpage said void pointer and I didn't know what that was yet. If nobody ever pointed that out to me, maybe I'd still be doing it today. This kind of "pedantry" you're accusing me of is how a lot of people get better.
By the way, the most popular compilers most people use today (llvm, gcc, MSVC) don't do what you're describing when the file ends in .c which it does here.
- ifr_name is cast to char pointer. It's already a char array.
- A few memcpy() calls cast their arguments to void pointer. This is just silly. All pointer types implicitly convert to that. This anti-pattern can create bugs with some 64-bit compilers if you fail to declare a function prototype (implicit `int` from undeclared function, cast into `void pointer` = bad times).
- The file ends in `.c`, but the return type of `malloc` is cast to different pointer types. This is a big "author has no idea what they're doing" red flag to me. In C you can implicitly convert void pointer to any other pointer type. It's not the same as C++. This also happens to let you fall into the "convert `int` to `void pointer` trap of the previous point.