47
Bugs Rust Won't Catch | corrode Rust Consulting - Analysis of Rust Coreutils (uutils) Bugs (corrode.dev)
submitted 3 months ago by to c/linux@programming.dev
22 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 11 points 3 months ago (1 child)

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

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
  • [–] 9 points 3 months ago (2 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 3 months ago (4 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)

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 3 points 3 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 months ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 months ago* (last edited 3 months ago)

    @davidgro That was a different thing. You can write or read from the physical memory address 0 even on the systems of the today - except that practically all the OS-es are using their paging or memory management to make that address unreeachable. Actually, as far I can remember, on Linux, the addresses between 0 - 65535 are mapped unreachable. If try to write them, you will get SIGSEGV. This is because a memory page is 4K, that is the granularity of the memory permissions. Beside that, we also need SIGSEGV (which would map to a "null pointer dereference" or analog) if it actually tried to access the part of a larger struct (what would be visible as an access to a non-zero, but very small memory address).

    C64 had no memory protection, you could read or write anywhere where you wanted. Although it had memory-mapped I/O, meaning that instead of bus-level port communication, all the IO, i.e. communication of the CPU with the chips of the mainboard, happened as if they would be memory. Some chip happily crashed the system on such writes, particularly the CIA did it (general purpose I/O chip and hw clock) for not enough well thought memory operations in the $DC00 - $DFFF range.

    You could happily write into 0 on C64. Actually, on the address 1, you could access the chip select pin of some RAM chips, meaning that you could with that switch from the basic ROM into an additional RAM area. Writing to the 0 byte did not had any on the spot visible effect on my experiments, but today I read in the docs, it had actually effect to the GPIO ports related to the memory chips managed at the address 1.

    Actually, c64 went even more: the first page, i.e. the addresses between 0-255, very accessible a bit faster, because they required a lesser amount of CPU and data bus cycles. Very important registers, used for important operations, were there.

    However, this all is about the C64 hardware. The C64 basic v2.0, which was written by the microsoft, quickly evaporating all my youth nostalgy, had nothing similar to the NULL (of C) or null (of Java). It not even had an "unset", "undefined" or similar type. The 3 types it had, were: 32-bit floating point, 16-bit integer and 0-254 byte long string.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 3 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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] -2 points 3 months ago (1 child)

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 3 months ago* (1 child)

    I can't claim to have learned them well, but I have used Java and various Basics over the last 30+ years.

    Which parts of my comment do you disagree with?

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

    @davidgro The way that #Rust guards memory is completely different to the way Java or Basic does. Rust is a fully compiled language suitable for systems programming, and the memory protection all happens at compile time; the runtime actually gains speed through the compilation process, rather than having the memory protection slow it down.

    The real difference is that the Rust compiler actually reads into the code it is compiling, rather than just making a mechanical translation.

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

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 3 months ago* (1 child)

    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.

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

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 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.

  • permalink
  • fedilink
  • source
  • parent