3 ms·
I've written a good deal of very high performance code that does a great deal of parsing such 'packed structs', and I intentionally do not use memcpy, for perfo
by usefulcat 8y ago
I've written a good deal of very high performance code that does a great deal of parsing such 'packed structs', and I intentionally do not use memcpy, for performance reasons. For one thing, note that many compilers never inline calls to memcpy--it's always a function call. In this kind of code, that alone is sufficient reason to avoid using it for accessing individual fields.
- usefulcat 8y ago> many compilers never inline calls to memcpy Sigh. Of course I say that, and then try to reproduce it on godbolt, and can't, at least not with a trivial example. So maybe that problem is not as widespread as I thought.
- camgunz 8y agoYeah I'm completely ok with reading into a packed struct. I think you may as well and indeed in most cases it's more explicit and succinct. I think using that internally leads to problems, so generally I advocate (if you're going to do this) using those as "packets" or whatever that are just PODs. You can validate those, then build higher level, internal structs from them. Generally I find whenever you see packed structs anywhere but the "I got this from the network/filesystem" level, the devs aren't considering taint analysis, which is a red flag to me. You shouldn't be dealing with external data outside a specific, well-defined layer.