Hacker News Reader

Hacker News

Comment by asdfasgasdgasdg | Hacker News Reader

Parent Full thread

asdfasgasdgasdg

> 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.

View on HN

I 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?

If 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?

The shift will automatically promote `b` to int, so the result is identical in both cases.

Thanks. I'm mostly paranoid about whether the ROL instruction has precedence over the OR ... ;)

> - Instead of network byte order, buf[offset] + buf[offset+1] * 256 .

And you got it wrong. Shows that there is no silver bullet.

I 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.

It isn't wrong if that was the order the bytes were packed on the sending side.

That is quite obviously a misquote done in haste, because the article includes the correct form (buf[offset] * 256 + buf[offset + 1]) :-).

The 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.

And 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.

Reply on news.ycombinator.com