uecker

4 ms·

1.
by uecker 7d ago
Please file a bug report, if you haven't done so.
2.
by uecker 10d ago
Maybe it is tolerated.
3.
by uecker 10d ago
You should move it yourself out of respect for the community.
4.
by uecker 10d ago
So it violates codeberg's policy.
5.
by uecker 11d ago
In reality, I think it much more about taking more control over parts of the ecosystem - the license change is part of it, but also getting rid of the old stubborn communities and maintainers.
6.
by uecker 11d ago
Maybe we could develop trustworthy free-software applications again, instead of trying to establish a commercial apps ecosystem on top of Linux?
7.
by uecker 13d 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&
8.
by uecker 13d 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
9.
by uecker 13d 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
10.
by uecker 13d 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.
11.
by uecker 13d 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.
12.
by uecker 13d 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
13.
by uecker 14d 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
14.
by uecker 14d 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
15.
by uecker 14d 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.
16.
by uecker 14d 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.
17.
by uecker 14d 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.
18.
by uecker 14d 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
19.
by uecker 14d ago
This is good news! Clang representatives were very basically the only ones against this clarification. Do you have a pointer?
20.
by uecker 14d 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
21.
by uecker 14d 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
22.
by uecker 14d 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
23.
by uecker 14d 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
24.
by uecker 14d 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
25.
by uecker 14d ago
This is not quite correct in C. ISO C at least requires that observable behavior until this point is preserved.
26.
by uecker 16d 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... "
27.
by uecker 16d 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
28.
by uecker 16d 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,
29.
by uecker 16d 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
30.
by uecker 17d 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

More ›