back
user profile
uecker
2,147karma·1,822submissions·April 14, 2020
about
Computational Magnetic Resonance Imaging, Real-time Magnetic Resonance Imaging, GCC Contributor, BART Toolbox, Member of ISO C WG14
recent activity (1,822 total)
comment
Well, memory safety is great but it seems Rust programmers also manage to create memory safety issues just fine: https://rustsec.org/advisories/RUSTSEC-2024-0401.html
https:…
comment
Many real world C programs have no UB. What Rust attempts to achieve is the possibility of accidentally introducing UB by designing the language in away that makes it impossible to have UB when sticki…
comment
This is certainly not true. Many programmers also learned to the use tools available to write reasonably safe code in C. I do not personally find this problematic.
comment
I started to like signed overflow rules, because it is really easy to find problems using sanitizers. The strict aliasing rules are not violated by typical POSIX socket code as a cast to a different p…
comment
What do you mean by C lacks many modern data structures?
comment
This good for you, other people reported problems with pragma once. And I think C is one of the better languages you could use to write code today. Also from the programs I use daily, the more stable …
comment
Ah sorry, I then I have indeed misread your comment.
comment
I do not think this analysis is correct. "char *foo" is not a cue in the wrong direction, it indicates that in "char *foo, bar" only foo is a pointer. Whether the syntax for declar…
comment
It is not supported everywhere and it uses some heuristic to determine that the file is actually the same one as used before, and this heuristic sometimes fails in complicated scenarios, e.g. with mul…
comment
It is neither portable nor obviously correct.
comment
There is the theory that Rust people constantly have to reassure themselves that the language is great and the future, so that can bear the suffering from using it.
comment
Not sure you are trolling us or not, but there is a bit of a contradiction between "here is a huge learning curve to Rust, one that I am still climbing," in the comment above and "is ju…
comment
That much is clear. It is not about safety. It is a cult around memory safety.
comment
Adding a package repository is a very conscious choice that also requires a password. Cut & pasting a line of code from we website is not. This is why a lot of time and effort was spend in the pas…
comment
You should also not add random apt repositories from the internet. But there is still a major different in terms of the implications for user education.
comment
C++ makes everything harder by tempting you with all the unnecessary tools. And some of the mental load only goes away if you can be 100% sure that nobody in the project uses the feature.
comment
I find it funny and sad at the same time that an installer for a "safe" programming language teaches people to download a shell script from a website and run it. What a farce.
comment
No, this is not how it works. Even without memory safety, the code has well-defined semantics for correct input, i.e. input that does not trigger undefined behavior. And if you prove your program cor…
comment
Then shouldn't these APIs be exposed as different libraries?
comment
It is tricky because it not specified simply as UB - at least in C. And the question is whether this specification is already the special case or not, and even if we want this special case or rather …
comment
For: A; // observable
B; // UB
and when A is reachable, the compiler can not remove A even if it sees at compile-time that B has UB when executed. This is the case in C …
comment
As it is based on my C paper, I can comment on this. While the compiler reasons at translation-time the question is whether an operation that UB is allowed to affect previous observable behavior at ru…
comment
Because looking up a macro name for each library is easier than adding a c file to your makefile? You could still always do #include "impl.c"
and this would still be nicer than #…
comment
I am not say it is hard. But I find having a .c/.h pair more useful and easier to work with.
comment
The issue if if you have many such libraries and any change to the implementation forces recompilation of everything. Maybe not such a big deal for such small libraries, but an annoying trend IMHO.
comment
Well, I do not use them at all. But I agree that this mechanism would avoid the additional copies. I have seen other single-header libraries though... In any case, forcing me to figure out the specif…
comment
I like simple code written in C, but when does this "single-header" nonsense stop? C has super nice and simple modularization via the classical .h/.c split which ensures fast compilati…
comment
X was a very well designed system IMHO that could be evolved via extensions (e.g. how compositing was added etc.). It is sad that few people work on it anymore to fix such issues.
comment
Sadly, this is a very valid concern.
comment
I think also pre/post conditions should look readable. But the Rust code referenced in the aritcle looks like what you would give a proof assistant, but then also only if you never plan to look a…