4 ms·
> Why not show some C/C++ code samples of the proper way to do it, then? He provides constructive examples for all of the items that he criticizes. - Instead
by asdfasgasdgasdg 8y ago
> Why not show some C/C++ code samples of the proper way to do it, then?
He provides constructive examples for all of the items that he criticizes.
- Instead of pointer arithmetic, base_ptr, offset, len.
- Instead of casting to internal structs, parsing into internal structs.
- Instead of network byte order, buf[offset] + buf[offset+1] * 256 .
- Instead of the wrong error codes, the right ones.
- Instead of random asserts over internal data structures, validation at parse time.
- clarry 8y ago> - Instead of network byte order, buf[offset] + buf[offset+1] * 256 . And you got it wrong. Shows that there is no silver bullet.
- asdfasgasdgasdg 8y agoI mean, I don't actually know what the correct way to do this is, because it's been a long time since I thought about endianness. I just wrote down roughly what I remembered from the article. Also, of course there is no silver bullet. Everyone knows that RCEs are still achievable against Python or Java servers. But there are still better and worse ways to do things, and there are certain categories of error that you cannot make in Python and Java that you can make in C, where the opposite is rarely the case.
- jjnoakes 8y agoIt isn't wrong if that was the order the bytes were packed on the sending side.
- alxlaz 8y agoThat is quite obviously a misquote done in haste, because the article includes the correct form (buf[offset] * 256 + buf[offset + 1]) :-).
- int_19h 8y agoThe silver bullet is to use the standard library that provides appropriate abstractions, such as byte streams with functions like "read a 32-bit little-endian integer". Nobody should actually be writing code like the above in most cases; and in the very very few cases where they have to (e.g. when forced to program in an environment where these haven't been provided), they should write it exactly once as a reusable function, complete with appropriate tests.
- tetha 8y agoAnd from experience, I find all of those tests for functions like this stupid, because the function is too trivial to write tests for. And then I always get the first 1 - 3 implementations wrong in some weird way, feel extremely stupid in the process and end up liking my tests.
- paavoova 8y agoI wonder why the author chooses to write buf[offset]*256 + buf[offset+1] instead of the more common method to load bytes using bitwise arithmetic, e.g. b[k]<<8 | b[k+1]. This is far clearer instead of using potentially magic numbers. Does Javascript not have bitwise arithmetic? Why would you write C code with Javascript in mind?
- michaelg7x 8y agoIf b is uint8_t you get zero if you <<8, but the expected value if you * by (int)256; or is it late and I should keep quiet?
- 0xffff2 8y agoThe shift will automatically promote `b` to int, so the result is identical in both cases.
- michaelg7x 8y agoThanks. I'm mostly paranoid about whether the ROL instruction has precedence over the OR ... ;)