71–80 of 93 posts
Interestingly, they have the OpenBSD version that does word-size assignments in asm for x86/arm. wonder why it wasn't being used. http://android.git.kernel.org/?p=platform/bionic.git;a=blob;... http://android.git.kernel.org/?p=platform/bionic.git;a=blob;...
Earlier quoted context omitted.
Any halfway decent software shop will have a policy of compiling with all warnings enabled FWIW, your definition of "halfway decent" would exclude most software shops in the world. It is extremely unprofessional to disable or ignore warnings such as the "unused function parameter" warning Unused function parameter warnings are often noise (e.g., due to #ifdefs, unimplemented APIs, backward compatible APIs, etc). I ag…
All I can say is than in 15 years (fuck.) I've never worked on a team that would have caught a bug like this in dead code. -Wall has been the gold standard on the teams I've worked on.
Earlier quoted context omitted.
memset sets a block of memory to a given value. It is often used to initialize an uninitialized block of memory to 0. So often, in fact, that this bug where it always initialized the memory to 0 survived so long.
on Google code search: "lang:c memset\(.+,\s [^0]+\s ,.+\)" return 32k results and "lang:c memset\(.+,\s 0+\s ,.+\)" returns 335k.
The thing that shocks me about this bug is that it should have been caught when the compiler issued a warning about an unused function parameter. Either the warning was not enabled, or the programmer just ignored it; either of those options indicates a pretty severe lack of professionalism.
The "unused parameter" error is one of the most useless of C compiler errors. There are dozens of perfectly valid reasons why a parameter would go unused, so the occasional error just gets lost in the noise. It's more helpful in C++, which can omit parameter names to indicate that it's intentionally unused. But then you're using C++; not worth the tradeoff.
Such as?
Earlier quoted context omitted.
I'll offer the tip that even if you have a fast memset, you can and should avoid using it when possible. Seeing memset is usually a sign that someone is being lazy about watching the length of their buffers and/or verifying their copies aren't off-by-one.
If I understand you correctly, you think programmers should say: int i; for (i = 0; i Instead of: memset(buffer, 0, SIZE) Because it indicates better buffer management.
If you need an array zeroed on first use, why didn't you use calloc? The only reason memset has for existing is when you need to reinitialize an existing array to zero. If things are so tight that you're wiping out an existing array and reusing it, which usually involves being deliberately less abstract than you'd naturally be, then, well, that's a pretty unusual situation.
(While we're on memset, I'd like to point out that the weirdest thing is that while memset initializes value byte by byte, the places where you do need a prefilled array are always places where the array is an array of larger values.)
Earlier quoted context omitted.
| The unused parameter warning is one of the biggest offenders in this area. And if you have a hundred warnings for unused parameters, which ones do you pay attention to? Well, so then you're exposed to this error. Do: void foo(int x) { (void)x; } to silence unused parameter warnings.
(void)x does not work on all compilers to silence the warning. gcc + cl != C.
Earlier quoted context omitted.
The "unused parameter" error is one of the most useless of C compiler errors. There are dozens of perfectly valid reasons why a parameter would go unused, so the occasional error just gets lost in the noise. It's more helpful in C++, which can omit parameter names to indicate that it's intentionally unused. But then you're using C++; not worth the tradeoff.
>There are dozens of perfectly valid reasons why a parameter would go unused, so the occasional error just gets lost in the noise. Such as?
1. An API-defined callback signature where you need to use (for example) the first and third parameters, and not the second.
2. A public API function that has become deprecated and the previous behavior is emulated in a way that doesn't require all the parameters.
3. Stub/wrapper functions.
4. Init/cleanup functions for modules written to a plugin API, when all parameters passed are not needed in all cases.
5. Language binding closure/thunk functions.
Most of the uses, I think, boil down to backwards compat and fixed callback/plugin interfaces. In those cases I think an __attribute__((unused)) or void cast aren't a huge burden. I usually turn on -Wunused-parameter just in case.
Earlier quoted context omitted.
What's with all the unused function parameters? Shouldn't that be an edge case?
Just about every callback interface takes a function pointer where the function expects a void * argument. Half the time it's not needed.
Now this is hacker news. We don't see too many of these types of posts.