IRC channel logs
2025-08-17.log
back to list of logs
<gnucode>I'm trying to update the hurd/running/debian.mdwn wiki page. All I see is there amd64 installer image. <youpi>see the same url with amd64 instead of i386 ;) <youpi>also, see the debian hurd port webpage <almuhs>hi. I'm trying to port the caesar translator to Rust. I've rewrote the main code to Rust, created a binding to libtrivfs, libports and libshouldbeinlibc, and try to compile. <almuhs>But when I try to compile i find a linker error, which i don't know how to solve <almuhs> /usr/bin/ld: /home/pruebas/hurd-translator-in-rust/Caesar Encryption Translator/caesar-rust/src/main.rs:282:(.text._ZN11caesar_rust4main17h6479bc55ec76ed4cE+0x4dd): undefined reference to `trivfs_fsid' <almuhs> /usr/bin/ld: /home/pruebas/hurd-translator-in-rust/Caesar Encryption Translator/caesar-rust/src/main.rs:282:(.text._ZN11caesar_rust4main17h6479bc55ec76ed4cE+0x508): undefined reference to `trivfs_fsid' <almuhs> /usr/bin/ld: /usr/bin/ld generated: undefined reference to `trivfs_fsid' <almuhs> /usr/bin/ld: /usr/bin/ld generated: undefined reference to `trivfs_allow_open' <almuhs> /usr/bin/ld: /usr/bin/ld generated: undefined reference to `trivfs_support_write' <almuhs> /usr/bin/ld: /usr/bin/ld generated: undefined reference to `trivfs_fstype' <almuhs> /usr/bin/ld: /usr/bin/ld generated: undefined reference to `trivfs_support_read' <almuhs> collect2: error: ld returned 1 exit status <almuhs>could you help me to solve this? <youpi>sneek: later tell almuhs see trivfs.h, it says "The user must define these variables", and see the texinfo documentation. Your translator has to provide these variables, to configure trivfs <azert>almuhs: I don’t know rust but it looks like a cumbersome language to learn <azert>I guess to start one have to add the unsafe keyword literally everywhere just so that it compiles, and then one figures out how to reduce their number <azert>if there is no ‘unsafe’ keyword, you get the false feeling that the code is bug free, until you find a bug <azert>again, I’m a total dumb stranger to any Rust concept <azert>I’m just cargo-culting what people say about it <identity>sneek: later tell azert unsafe does not work that way: it allows you to, among other things, call unsafe functions and dereference raw pointers, while Rust's references (safe pointers) stay under the supervision of the borrow checker; while Rust's ownership model feels cumbersome at first, it merely encodes reasonable code practices, like not mutating a variable (or a buffer, or a file, or anything) from multiple places, or not reading <sneek>Welcome back azert, you have 1 message! <sneek>azert, identity says: unsafe does not work that way: it allows you to, among other things, call unsafe functions and dereference raw pointers, while Rust's references (safe pointers) stay under the supervision of the borrow checker; while Rust's ownership model feels cumbersome at first, it merely encodes reasonable code practices, like not mutating a variable (or a buffer, or a file, or anything) from multiple places, or not reading <azert>thanks for the very insightful information <azert>but let’s take the second use case: unsafe will clearly give you a reason to use rust references vs raw pointers in your code <azert>as such, you’ll probably end up removing the unsafe word at some point, right? <azert>and about the first usecase, you’d expect unsafe functions to be called rarely <ThinkT510>if you can do it in safe rust then you usually should. sometimes you can use unsafe for performance reasons but the convention is to provide a SAFETY comment describing why it is used and any invariants that need to be observed <identity>azert: you generally start without the unsafe keyword and only start using it when you really need it, like when interfacing with C code, for example; most of the standard library (and most third-party libraries, too) return references, so you would have to do a lot of ugly ref-to-raw-pointer casts, and you can not cast raw-pointer-to-ref iirc <identity>generally instead of calling unsafe functions directly, you use a wrapper that does something reasonable when you call it incorrectly, while unsafe code sometimes uses an assertion macro to crash the program if continuing would invoke undefined behaviour <azert>what about syscalls? Are those unsafe? How does Rust code interface with the standard C library for things like open, read, close <azert>I guess they use the standard Rust library instead and that it provides equivalent functionality <azert>But let’s say you are the person that started the standard Rust library, avoidining unsafe is not an option <azert>you’d end up with the work I mentioned above <ThinkT510>sometimes unsafe is unavoidable but you are always able to encapsulate it <azert>in other words, almuhs will end up writing a libports wrapper, a libtrivfs wrapper and so on. And in those wrappers he will need to carefully reduce the amount of unsafe keywords starting from “a lot of them” going to “only where required in an elegant way”? <ThinkT510>bindings by their very nature neccessitate unsafe <identity>it is generally easier to maintain invariants on an unsafe function boundary than across the whole codebase <azert>Although the project seems abandoned <azert>it can possibly be resurrected for GNUMach