5 ms·

The redis wire protocol is simple enough where it's not very difficult. It's instructive to write it in C because there's a lot of translatable knowledge to oth

The redis wire protocol is simple enough where it's not very difficult. It's instructive to write it in C because there's a lot of translatable knowledge to other languages: read in a buffer, cast that buffer to the protocol-specific struct, read the various fields from memory, etc. Basic operations for a systems-level project like this.

yazzku 4y ago
It's simple enough, and yet: https://nvd.nist.gov/vuln/detail/CVE-2021-32675 https://nvd.nist.gov/vuln/detail/CVE-2021-32675 https://nvd.nist.gov/vuln/detail/CVE-2021-41099 https://nvd.nist.gov/vuln/detail/CVE-2021-41099 https://nvd.nist.gov/vuln/detail/CVE-2021-32761 https://nvd.nist.gov/vuln/detail/CVE-2021-32761 I agree it's instructive, but on the other hand, the time might be right to start teaching why not to do this stuff. Modeling a protocol parser in a high-level language that can spit up correct and highly-optimized C code would be just as instructive and perhaps even more fun.
- blagie 4y ago
  <-- This. Yes, "read in a buffer, cast that buffer to the protocol-specific struct, read the various fields from memory, etc" are all operations one should generally NOT do. This was instructive maybe three decades ago, when the internet was relatively safe. Knowing how to do this RIGHT is important. The place this is still helpful is low-level programming, and embedded is a far better place to learn. If one part of your microwave is talking to a sensor, security isn't really an issue, since you control both ends.
  - yazzku 4y ago
    Yeah, and I said the above being myself a big fan of C. I write C in my hobby projects. Yet if I were doing anything non-trivial that talks over the network, that protocol parsing would for sure not be hand-written.
    - blagie 4y ago
      I really enjoyed writing low-level C code, maybe three decades ago. I grew out of it, eventually, but I remember the joy. Similar for assembly, actually. (And rereading, I don't mean "growing out" in a derogatory way -- I grow into and out of a lot of things -- and low-level programming is something anyone can enjoy for a few years)

yazzku 4y ago

It's simple enough, and yet: https://nvd.nist.gov/vuln/detail/CVE-2021-32675 https://nvd.nist.gov/vuln/detail/CVE-2021-32675 https://nvd.nist.gov/vuln/detail/CVE-2021-41099 https://nvd.nist.gov/vuln/detail/CVE-2021-41099 https://nvd.nist.gov/vuln/detail/CVE-2021-32761 https://nvd.nist.gov/vuln/detail/CVE-2021-32761 I agree it's instructive, but on the other hand, the time might be right to start teaching why not to do this stuff. Modeling a protocol parser in a high-level language that can spit up correct and highly-optimized C code would be just as instructive and perhaps even more fun.

blagie 4y ago
<-- This. Yes, "read in a buffer, cast that buffer to the protocol-specific struct, read the various fields from memory, etc" are all operations one should generally NOT do. This was instructive maybe three decades ago, when the internet was relatively safe. Knowing how to do this RIGHT is important. The place this is still helpful is low-level programming, and embedded is a far better place to learn. If one part of your microwave is talking to a sensor, security isn't really an issue, since you control both ends.
- yazzku 4y ago
  Yeah, and I said the above being myself a big fan of C. I write C in my hobby projects. Yet if I were doing anything non-trivial that talks over the network, that protocol parsing would for sure not be hand-written.
  - blagie 4y ago
    I really enjoyed writing low-level C code, maybe three decades ago. I grew out of it, eventually, but I remember the joy. Similar for assembly, actually. (And rereading, I don't mean "growing out" in a derogatory way -- I grow into and out of a lot of things -- and low-level programming is something anyone can enjoy for a few years)