4 ms·
> - Instead of network byte order, buf[offset] + buf[offset+1] * 256 . And you got it wrong. Shows that there is no silver bullet.
by 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.