| 14 Jan 2025 |
 ganipote | https://opensource.googleblog.com/2025/01/google-summer-of-code-2025-is-here.html | 23:35:16 |
 Ron Williams | Thanks, I will look into it. | 23:49:48 |
| 15 Jan 2025 |
 Ribbon | Nice.
https://www.phoronix.com/news/Intel-Perf-Tips-Linux-Graphics | 10:53:37 |
| Ribbon | https://www.phoronix.com/news/Rsync-3.4-Released | 10:54:19 |
| Ribbon | NICE.
https://www.phoronix.com/news/AMD-Preferred-Core-Better-6.14 | 12:41:59 |
| Ribbon | NICE!!
https://www.phoronix.com/news/Xen-RISC-V-Linux-Patches | 12:43:04 |
| Ribbon | https://www.phoronix.com/news/GNOME-48-Triple-Buffering-Jan | 15:19:14 |
| Ribbon | https://www.phoronix.com/news/Linux-6.14-PCIe-NVMe-Target-EPF | 17:08:30 |
|  teskje joined the room. | 17:12:54 |
| ganipote | https://corrode.dev/blog/prototyping/ | 17:18:05 |
| ganipote | * https://corrode.dev/blog/prototyping/
About prototyping in Rust | 17:34:12 |
 gimmedasauce | 
Download image.png | 19:42:00 |
| gimmedasauce | what even is the question here | 19:42:16 |
| Ribbon | It doesn't make any sense, lol. | 19:44:55 |
| gimmedasauce | wasn't expecting a response
technically i didn't get one
not to my request for a source stating that memory leaks were ever considered unsafe in rust | 19:45:07 |
| gimmedasauce | the docs say that there was discussion about making them unsafe but the devs realized it was insane to try | 19:46:26 |
| Ribbon | AMAZING!!
https://www.phoronix.com/news/Intel-THC-For-Linux-6.14 | 19:56:37 |
| teskje | In reply to @gimmedasauce:matrix.org
wasn't expecting a response
technically i didn't get one
not to my request for a source stating that memory leaks were ever considered unsafe in rust I have no context on your discussion, but here is a source: https://rust-lang.github.io/rfcs/1066-safe-mem-forget.html | 20:22:04 |
 auronandace | Seems to be pointing out that if a system runs out of memory due to a memory leak then it will result in undefined behaviour.
If you have no more memory then what happens when you try to allocate something? That entirely depends on the allocator you are using. That is firmly in unsafe territory. They can assume infallible allocation which could lead to undefined behaviour. | 20:28:52 |
| auronandace | This is why it is important to identify and fix any unintentional memory leaks. | 20:29:58 |
 bjorn3 | If GlobalAlloc::alloc fails, it will return a NULL pointer, which callers are supposed to either gracefully handle or call std::alloc::handle_alloc_error, the later of which currently always aborts (no UB), but may also panic (no UB). In low memory conditions the kernel may also decide to OOM kill (no UB), the target of which can be any process, including one which hasn't allocated any memory ever (eg because the executable size is bigger than the total size of all other processes, or just because all other processes have the OOM adjustment such that they won't ever get OOM killed). | 20:37:12 |
| bjorn3 | I repeat, leaks do not cause UB! | 20:37:51 |
| bjorn3 | Leaks are correctness issues, but not safety issues. | 20:38:12 |
| auronandace | Awesome, thanks for the clarification! | 20:38:20 |
| auronandace | The safety section seems to suggest a panic can lead to memory unsafety: https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html | 20:40:38 |
| bjorn3 | GlobalAlloc::alloc itself may never panic, but std::alloc::handle_alloc_error may. | 20:42:20 |
| auronandace | Ah, so how you implement it. | 20:42:45 |
| bjorn3 | A GlobalAlloc::alloc impl must report allocation failure by returning a NULL pointer, not by unwinding. | 20:42:54 |
| auronandace | https://seanmonstar.com/blog/2024-in-review/ | 21:00:52 |
| Ron Williams | Even if the allocator returns an error instead of panicking, you can still run out of stack, which is admittedly harder to deal with. So technically, calling a function is as unsafe as allocating on the heap. To make using memory "safe", you would have to have a function caller that returns error if it's out of stack space and an allocator that returns error if it's out of heap space. | 21:56:37 |
