uecker

12 ms·

1.
by uecker 4d ago
Yes, other resource leaks can cause similar problems, this just does not have much to do with memory, so calling it "memory safety" would be strange. On the other hand, including "memory leaks" under "memory safety&
2.
by uecker 4d ago
It does not have to fully specify what happens in each case, Fil-C only formulates a bound that guarantees that any memory access is limited to the memory that can legitimately be accessed. That safety checks can be removed, where the opti
3.
by uecker 4d ago
I will take the bait. The reasons I use C: Fast compilation times, long-term stability, portability to many architectures, multiple implementations (no lock-in to a single industry controlled implementation), high performance, conceptually
4.
by uecker 4d ago
Fil-C is a fork of clang that explicitly defines all these things to have bounded behavior, so ignoring exactly this - the whole point of Fil-C - makes no sense.
5.
by uecker 4d ago
To decide what is defined or not, you need to reference the relevant specification. The specification is not ISO C, but ISO C plus additional guarantees by Fil-C.
6.
by uecker 4d ago
This depends on the definition. Rust originally included leaks in their definition of unsafe and later changed the definition when they found out that they can not reliably prevent leaks. Leaks could reasonably be considered unsafe as they
7.
by uecker 4d ago
I agree that searching for "unsafe" is easier, we should have this in C too. I have some local patches to GCC that emit diagnostics for some things which are unsafe in C and were GCC does not already have a warning. I think the c
8.
by uecker 4d ago
And my point is that "do not do low-level pointer arithmetic" is not really much harder to follow in practice than do not use "unsafe". In safety critical systems you may also care about panics, memory leaks, etc. I am
9.
by uecker 4d ago
I wish somebody would build a C version of xpra which does only has the client side for latency hiding and manages the remote caching using X11 messages only.
10.
by uecker 4d ago
Whatever happens for the other UB remains bounded memory safely in Fil-C. (according to a definition of memory safety that excludes protection of subobject bounds, but Rust also redefines memory safety to what the Rust compiler can do, e.g.
11.
by uecker 4d ago
True, if you do pointer arithmetic on C strings or similar low-level buffer operations without introducing safe abstractions, there is basically no way to do this safely.
12.
by uecker 4d ago
I was only speaking for C not C++ (I fled C++ a long time ago). My code usually works first try in C, but my experience also working with students is that you need to learn to use safe patterns and strategies first. I can imagine that Rust
13.
by uecker 4d ago
This is good news! Clang representatives were very basically the only ones against this clarification. Do you have a pointer?
14.
by uecker 4d ago
I think this is a bit exaggerated. I mostly find it not difficult to avoid UB in C. There are mainly five areas where you can have problems: type safety issues, signed integer overflow, out-of-bounds accesses, use-after-free, and race cond
15.
by uecker 4d ago
There are a few rare cases where compiler optimization will fail this in GCC. There are also cases where the C spec has defined behavior that optimizers break. Where I know about them, I file bugs. It would be up for users to insist that th
16.
by uecker 4d ago
For, C we have already removed at lot of UB from the working draft for C2y. My hope is that only the UB is left that is difficult to remove without requiring extensive changes to code or compilers, and that this can then be addressed by a t
17.
by uecker 4d ago
It follows from the definition of UB: undefined behavior: "behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this document imposes no requirements" The C++ spec at some point change
18.
by uecker 4d ago
The compilers are mostly doing the right thing (not always). The C standard specifies what is considered an effect on the outside world, i.e. file I/O and volatile accesses. For concurrent programming, there is also a memory model that
19.
by uecker 4d ago
This is not quite correct in C. ISO C at least requires that observable behavior until this point is preserved.
20.
by uecker 6d ago
Here seems to be the ABI, but I am not sure it is the right one and I am not sure if there are not different ABIs around. https://go.googlesource.com/go/+/refs/heads/dev.regabi/src/c... "
21.
by uecker 6d ago
Yes, but this this is not a problem at all because any bug caused by misuse of unsafe (or unwrap) is entirely the fault of the programmer (or the AI) and not of Rust. /s
22.
by uecker 6d ago
I am confused why you cite these languages as an example to your claim that closures are preferred over nested functions in language design (which is already a confusing statement), as many of them do have nested functions, e.g. Go, Julia,
23.
by uecker 7d ago
Equivalency does not mean that the everything has to be identical or even that the code has to be exactly identical for different implementations. My point is that the implementation is structurally very similar: You synthesize a structure
24.
by uecker 7d ago
An example showing this equivalency is this: https://godbolt.org/z/vEP5G9Pfr Similar to how std::function_ref creates a thunk in C++ that calls the lambda so that it has a generic type-erased API that can be passed to
25.
by uecker 7d ago
The ABI does not need to be compatible, because there is no way to call a C++ lambda directly from C. If you take the address of a lambda function you get a pointer to an object of anonymous type, so you can not pass it to qsort, and qsor
26.
by uecker 7d ago
I can not write the signature of a function that requires a static chain (which exist in many languages) in C, because we have not added such a feature to the language. But we could. And we should, because we now need a (type-unsafe) exten
27.
by uecker 7d ago
Thanks! This is cool. In need to do some reading...
28.
by uecker 7d ago
Well, the affected arrayref crate was downloaded 2k times. It is also not the first case. If AI magically finds all bugs in short time we have no problems anyhow. We also do not need Rust. A minimum age requirement is a good thing, but also
29.
by uecker 7d ago
No, why? It simply means that the arguments are in different registers.
30.
by uecker 7d ago
This is not my experience.

More ›