| 20 Mar 2026 |
emily | (e.g. a moving collector is certainly a bit rough and brings its own constraints, though those aren't particularly fun to interface with in C++ either) | 12:51:18 |
piegames | In reply to @emilazy:matrix.org did you read the blog post? :) Years ago | 12:52:17 |
| @draupnir:lix.systems left the room. | 13:21:43 |
| Patrick changed their display name from patrickdag to Patrick. | 14:52:31 |
@rosssmyth:matrix.org | There is memory management toolkit
https://www.mmtk.io/ | 16:25:53 |
raitobezarius (DECT: 7248) | (yeah lix people looked at it a couple of times) | 16:26:26 |
| 21 Mar 2026 |
ShalokShalom | There is also https://fil-c.org/ | 12:32:23 |
piegames | Fil-C is awesome | 12:42:59 |
piegames | Except that memory safety is not our main problem with C++ | 12:43:37 |
K900 | I do wonder if cppnix built with fil-c would be 10x slower or less somehow | 13:10:06 |
ShalokShalom | I read that compiled stuff becomes significantly slower, and that people use it to detect the issues, and not to run it it production. | 13:11:03 |
ShalokShalom | What is? | 13:11:18 |
raitobezarius (DECT: 7248) | Fil-C is not memory safe | 13:13:45 |
raitobezarius (DECT: 7248) | Don't see any interest in that thing | 13:14:21 |
piegames | In reply to @shalokshalom:kde.org What is? Ergonomics, developer experience, stdlib | 13:15:45 |
aloisw | It isn't? Memory safety is basically their headline claim … | 13:16:04 |
piegames | Like, have you tried writing C++ code? C++ iterators are a work of madness | 13:16:32 |
Qyriad | ^^^^^ | 13:18:14 |
raitobezarius (DECT: 7248) | it doesn't solve data races, it doesn't any sort of reasoning over mutable aliasing | 13:18:16 |
raitobezarius (DECT: 7248) | it has a spatial safety instrumentation pass to clang (so out of band accesses) | 13:18:36 |
raitobezarius (DECT: 7248) | a runtime support library and a concurrent GC for temporal safety | 13:18:45 |
Qyriad | Writing production C++ is like writing production Bash. It is extremely difficult to write Correct C++ code and it is extremely difficult to debug | 13:19:02 |
raitobezarius (DECT: 7248) | "memory safe, bounds checked, GCed ahead-of-time languages" (in the sense Fil-C claim to be) have been existing for a long time | 13:19:26 |
raitobezarius (DECT: 7248) | * it doesn't solve data races, it doesn't do any sort of reasoning over mutable aliasing | 13:20:12 |
aloisw | "Doesn't solve data races" in the C "they are still undefined behaviour" sense or in the Java "you may get weird values, but nothing bad happens otherwise" sense? | 13:31:10 |
raitobezarius (DECT: 7248) | still UB | 13:32:07 |
raitobezarius (DECT: 7248) | anything that atomically updates a pointer must use the LLVM IR atomics in Fil-C | 13:32:26 |
raitobezarius (DECT: 7248) | (and so if you store a pointer in one thread and load in another, you may have tearing betwen the addr and caps parts of that pointer) | 13:32:58 |
K900 | Honestly fil-c is a good sanitizer | 13:33:18 |
K900 | It's just not any of the things they advertise it as | 13:33:30 |