all 19 comments

sorted by: hot top controversial new old
[–] 10 points 6 months ago (12 children)

Rust or any other compiler can't catch those type of bugs because they are not bugs at compiler level 🤷

  • source
  • hideshow 12 child comments
  • [–] 9 points 6 months ago (11 children)

    We said the same about memory safety: That's something a compiler can not solve. Now it does.

    It is nice to see that sometines things do improve.

  • source
  • parent
  • hideshow 11 child comments
  • [–] 2 points 6 months ago (6 children)

    I thought one of the goals of Java and similar was partial memory safety? If it didn't have null it seems it would be most of the way there.

    And don't forget Basic. Yeah most variants had pointers and equivalents to null, but they are 'advanced' and not meant for general code. (Although that's interpreted and you said compiled, often it could be 'complied' similarly to Java bytecode)

  • source
  • parent
  • hideshow 6 child comments
  • [–] 3 points 6 months ago (1 child)

    @davidgro @hunger Last basic variant I worked with was the basic of the commodore machines. It had no NULL. I have also seen vbscript a little, afaik also it had not.In Java, null does not mean a real 0 value, I think it is more like a static const, more similar to the None type of the Python. Its name is only a helper for the C/C++ guys to better understand a stack trace.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 6 months ago

    Ah, yeah looks like address 0 is nothing special on C64. I was thinking more about things like Qbasic and especially Visual Basic where dereferencing address 0 expecting a string or object is easy enough to do.

  • source
  • parent
  • [–] 2 points 6 months ago

    A null does not make it memory unsafe. You aren't accessing invalid memory, the runtime just raises a NRE. Which is fine. No memory safety violated.

    Java is, as long as you stick to pure java and not native interop, entirely memory safe. And that's achieved by giving up control of memory allocation to the garbage collector.

    Rust is not the first memory safe language. It does however, manage to achieve memory safety without needing a garbage collector. Which is what drew my initial interest.

  • source
  • parent
  • [–] -2 points 6 months ago (1 child)

    @davidgro @hunger Learn the three languages you are talking about before talking about them. Ill-informed thoughts impress no one.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 6 months ago (3 children)

    Memory safety is something compiler understands and has under control, this stuff it does not. Nor it should.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 3 points 6 months ago* (2 children)

    Many of their TOCTOU issues are something a type system can help with. Require operations to execute on a fd handle directly rather than using convenience functions.

    let fd = FileDescriptor::new(path);
    fd.delete()?;
    fd.create(mode)?;
    
    let is_root = fd == FileDescriptor::new("/"); // does (dev, inode) comparison internally
    // etc
    

    The uutils devs would need to create that themselves, but OpenOptions seems to get them part of the way there at least.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 6 months ago (1 child)

    That's a question of API, not type system. And FD types (e.g. OwnedFd, BorrowedFd) are already in std.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 6 months ago

    That's a question of API, not type system.

    It's only enforced because of Rust's strict type system. Python, on the other hand, lets you do whatever you want by comparison, and complains only at runtime. I've seen far too many **kwargs for my liking.

    And FD types (e.g. OwnedFd, BorrowedFd) are already in std.

    My example would be a thin wrapper around these, most likely. It's only an example of what I'm trying to convey, though.

  • source
  • parent
  • [–] 7 points 6 months ago*
    // Don't bail on the first error, but remember the worst one.
    let mut worst = 0;
    for file in files {
        if let Err(e) = chmod_one(file) {
            worst = worst.max(e.exit_code());
        }
    }
    process::exit(worst);
    

    This is not rustic, I feel.

    files.iter()
      .map(chmod_one)
      .filter_map(Result::err)
    

    is more like it.

    From there, you can next() for first error, last() for last error, or fold() for max error, or collect() if you need to save all errors.


    And no, static compilation doesn’t help here, because get_user_by_name goes through NSS, which dlopens libnss_* modules at runtime regardless of whether your binary is statically linked.

    This is not true in musl systems. I just quickly checked in a Chimera rootfs (which has a system dynamic musl libc btw).

    I believe the described dlopening is one of the well known reasons why GNU libc is not suitable for static linking, unlike musl!

    In Arch, this indeed loads /usr/lib/libnss_systemd.so.2.

    Everyone can test this with strace id 2>&1 | egrep 'open.*\.so'.

  • source
  • [–] 2 points 6 months ago

    Don’t Trust a Path Across Two Syscalls

    Wasn't this a common knowledge among application developers? File system is volatile, and can change any time, do not assume persistence of it. I heard about the principle from ghcup developer a few years ago.

  • source
  • [–] 2 points 6 months ago

    Author couldn't help himself but do some "wisdomry" at the end!

  • source
  • [–] 2 points 6 months ago (2 children)

    Time for Haskell?

    How many more bugs would Haskell catch?

    "Entire classes of bugs"?

  • source
  • hideshow 2 child comments