Remix.run Logo
johnisgood 3 days ago

  pub fn read<P: AsRef<Path>>(path: P) -> io::Result<Vec<u8>> {
    fn inner(path: &Path) -> io::Result<Vec<u8>> {
      let mut file = File::open(path)?;
      let mut bytes = Vec::new();
      file.read_to_end(&mut bytes)?;
      Ok(bytes)
    }
    inner(path.as_ref())
  }
"aBsTraCtiOnS aRe gOod"... Right.

Reference implementations must NOT have abstractions like this. Rust encourages it. Lots of Rust codebase is filled with them. Your feelings for Rust is irrelevant. C is simple and easy to understand, therefore reference implementations must be in C. Period.

...or Common Lisp, or OCaml... why not?!

Ar-Curunir 3 days ago | parent [-]

(a) that is a fairly easy to understand piece of code. Are you complaining about the definition of the inner function?

(b) the equivalent C code would look pretty similar.

(c) this is not cryptographic code

johnisgood 3 days ago | parent [-]

(a) I'm complaining about the messed up syntax and symbol soup.

https://github.com/ioccc-src/winner/blob/master/2024/burton/...

This code is fairly easy to understand, too, then.

(b) No, it would definitely not look "pretty similar".

(c) So what? You talked about abstractions in cryptographic code. Abstractions are layers to hide things. That is bad in crypto code.

Ar-Curunir 2 days ago | parent [-]

Hiding things is totally great in crypto code! When I’m implementing signature verification, I shouldn’t have to worry how the underlying, eg, field or elliptic curve algebra is implemented!

In fact there have been many crypto bugs which insufficiently abstract this kind of stuff away.