I disagree with this author on both counts.
1. Zero filling is theoretically unnecessary, yes. But theory is not often reality. Zero filling is a defensive measure that protects you from other code that makes unhealthy assumptions. Code external to yours may make assumptions about what lies in your padding, either by doing memcmp's, or adding new fields in a later version of the struct and intending it to be ABI compatible between modules. I'll prefer safe and evolvable code over your nitpick about how it's initialized, thank you very much.
2. Consider yourself lucky that you only use free() in your code. In more complex code bases, custom allocators are used. They do not always follow the same semantics as are dictated for free().
Maybe instead of saying "this perfectly valid thing drives me nuts", ask why people do it. It's not because they don't know better.
Stop Memsetting Structures
91–100 of 277 posts
Re: Stop Memsetting Structures
#92Because it’s 2019! It really irritates me when people give arguments like this. I seriously don't care what year it is, I care that the code I write works. A lot of projects still use C89 because they want the widest portability. C99 isn't very new, but especially in the embedded and other niche industries, C89 (often with some extensions) is all you get. That said, "= { 0 };" is almost always usable instead of a mem…
I just had to google it:
https://stackoverflow.com/questions/1912325/checking-for-nul...
There is history to this practice. And also, foresight: 1) I may want to redefine free(). 2) If I do, my free() does not null-check. 3) Which is why my main code would null-check.
I'm an embedded developer, never do much on application work, and used to do that with C++, so I'm not too familiar with the heap allocation intricacies with C. But I'm quite sure that "delete" in C++ e.g. definitely needs to be null-checked (unless they changed that in some newer C++ revision, I always to try to code version-agnostic, and so far, have always managed).
In practice, I find it better to manually null-check pointers before deleting their contents, it either gets optimized away anyways or is an extra redundancy in code-or platform-migration.
Re: Stop Memsetting Structures
#93Earlier quoted context omitted.
I think they simply don't do that with structs that contain pointers?
Indeed, this. If you have data with pointers, you either need to flatten (read: copy) your structure into something appropriate for structuring, or just get a proper serialization layer.
I guess there could be some fun workarounds with ptrdiff_t instead of pointers. "My child is 1000 bytes that way in memory" etc.
Re: Stop Memsetting Structures
#94Earlier quoted context omitted.
Nope, memset will often be “optimized” such that padding is not zeroed. It’s not because the compiler sees that padding isn’t observed, it’s because reading from padding is undefined. Because reading from padding is undefined the write (also undefined) by definition has no observable side effects. Memset_s is the only way to guarantee that padding is actually zeroed, well memset or bzero_s obviously. It’s critically…
Right, but zeroing padding only matters for security reasons. If your memset isn't being done for security reasons, then memset() is better than memset_s().
I just realized you might be thinking of security in the sense of keys/partial keys.
Things that matter:
* vtable and code pointers: leaks the aslr slide
* data pointers: leak heap location
* type ids: can be used to spoof objects
* length and size fields: can give you information about heap layout
Etc etc.
All of these get attacked.
Re: Stop Memsetting Structures
#95Does that also zero the padding that may exist between elements of the structure (or at its end)? Because if not, not memset'ing will open you up to all kinds of info leaks, especially if you plan to send that struct over the network (or to another process, or from kernel to userspace...). EDIT: Actually I have to apologize, because I’m not certain what the C standard says about whether the padding bytes can change w…
Sending structures that include padding or that you don’t know the exact layout of over the network is another thing you shouldn’t do, period. Code doing that may break with a compiler change or a compilation flag change on one end of the connection, even if you can guarantee both ends use the same CPU.
RDMA (Infiniband) does DMA to/from network. Why we should not use RDMA?
Re: Stop Memsetting Structures
#96Because it’s 2019! It really irritates me when people give arguments like this. I seriously don't care what year it is, I care that the code I write works. A lot of projects still use C89 because they want the widest portability. C99 isn't very new, but especially in the embedded and other niche industries, C89 (often with some extensions) is all you get. That said, "= { 0 };" is almost always usable instead of a mem…
#include struct abc { int a; int b; int c; }; int main() { struct abc b = {2}; printf("a b c = %d %d %d\n ", b.a, b.b, b.c); return 0; } % c99 test.c % a.out a b c = 2 0 0
Absolutely! This is why I'll iterate through all and manually set each and every single element. You can even do it in one line, too: for (unsigned int i = 0; i EDIT: Just noticed your code example uses structs. My example is for arrays, for which these observations are also correct.
Re: Stop Memsetting Structures
#97Am I the only one who finds this int yes=1; setsockopt(listener, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof (yes)) ; much cleaner than this setsockopt(listener, SOL_SOCKET, SO_REUSEADDR, &(int) {1}, sizeof(int)); ?
No, you're not, the second part is like random json data inside C source.
Re: Stop Memsetting Structures
#98A new edition of K&R that is edited to address the new features that have been added since C89. I suppose that some might argue that there isn't much need for a new edition because anyone who can grok C89 could probably grok the rest themselves Internet-based self-teaching, but I would pay good money to have all those resources in consolidated into one printed resource.
Re: Stop Memsetting Structures
#99Because it’s 2019! It really irritates me when people give arguments like this. I seriously don't care what year it is, I care that the code I write works. A lot of projects still use C89 because they want the widest portability. C99 isn't very new, but especially in the embedded and other niche industries, C89 (often with some extensions) is all you get. That said, "= { 0 };" is almost always usable instead of a mem…
I just had to google it: https://stackoverflow.com/questions/1912325/checking-for-nul... There is history to this practice. And also, foresight: 1) I may want to redefine free(). 2) If I do, my free() does not null-check. 3) Which is why my main code would null-check. I'm an embedded developer, never do much on application work, and used to do that with C++, so I'm not too familiar with the heap allocation intricacie…
I may want to redefine free(). 2) If I do, my free() does not null-check.
I think redefining standard functions to do something very unexpected is very poor decision, especially when it means you now have to burden all its callsites with an extra check.
But I'm quite sure that "delete" in C++ e.g. definitely needs to be null-checked (unless they changed that in some newer C++ revision
No, it was never needed in C++ either (which given its desire to be backwards-compatible with C, is not surprising.) From the C++98 standard section 5.3.5, paragraph 2: "if the value of the operand of delete is the null pointer the operation has no effect."
Re: Stop Memsetting Structures
#100Earlier quoted context omitted.
Same. But also, I feel like most of The Force's efforts are directed at C++. I could be wrong.
Rust is a big language, like C++. It feels too complicated compared to C.
I've only written a little of each, but my impression is that C has mostly remained a focused, effective language for careful systems programming. While C++ has become a sprawling cthulhu of leaky abstractions and other nasty foot-guns and people only use it because "it's as fast as C but sorta feels like a higher-level language". And that therefore Rust is a strict improvement over C++, but not necessarily C.