uecker

13 ms·

331.
by uecker 5mo ago
The "stronger type system" is mostly a myth in my opinion. It was true in the past in pre-prototype C. The void pointer rules are better in C IMHO as they avoid unneeded casts (that then remove more type safety) and FAMs and varia
332.
by uecker 5mo ago
You can just run it through a compiler in c++ language mode.
333.
by uecker 5mo ago
There is not much real evidence for "devs wrongly assume" and as someone writing numerical code (clusters, NUMA, SIMD, etc.) I think C is still the ideal tool for this.
334.
by uecker 5mo ago
The "nor is the hardware a PDP 11". Byte access was the main new feature of the PDP 11 that C adopted. Are you saying being able to access individual bytes is not relevant on modern hardware?
335.
by uecker 5mo ago
In practice, the [static n] notation can give you useful warnings and bounds checking. https://godbolt.org/z/PzcjW4zKK And while the (*array_ptr)[3] notation take a moment to get used to, it is very logical. If you hav
336.
by uecker 5mo ago
Yes, but this GCC behavior is not conformant to ISO C.
337.
by uecker 5mo ago
Yes, I do not believe for a second that wayland is a net benefit for the majority. Every improvement one can have in Wayland could have been implemented in X without breaking compatibility, without causing all the regressions and limitation
338.
by uecker 5mo ago
The quiz is not entirely accurate though. For example, pointers to the same address must compare equal. Other stuff is ancient and some of it was already removed in C23. Again other things are entirely irrelevant in practice and kept only f
339.
by uecker 5mo ago
Not my experience and we have lot of Linux machines. Drivers and hardware expectations of programs certainly change over time, but this has not much to do with Wayland vs X.
340.
by uecker 5mo ago
Sure, they know best of course ;-) This is the arrogance and gas lightning we are talking about. But I am not complaining about KDE, they can do whatever they feel best for their projec.t I do not use KDE and - if they make decisions like
341.
by uecker 5mo ago
This sounds more like random configuration problems with your drivers. The rendering model for modern X clients is the same as for Wayland, so the idea that there could be room for a fundamental improvement is based on misinformation.
342.
by uecker 5mo ago
Well, I can only report from my experience and this is the pain I still see with Wayland but not really with X. If KDE wants to hurt some of their users, this is their decision.
343.
by uecker 5mo ago
It might matter to some but not to many, and in practice the pain imposed on many others could have been avoided by simply improving X. That developers already like to rewrite things is well known, but nobody should pay for this.
344.
by uecker 5mo ago
Is is a regular occurrence that students in my lab that use or switch to Wayland still run into problems. Switching back to X11 reliably works as a fix. The sad thing is that there is also no apparent advantage to Wayland, it is just pushed
345.
by uecker 5mo ago
yes, exactly this.
346.
by uecker 5mo ago
It looks better to me than the other macro solution as it is more transparent what is done compared to DEFINE_ENUM. But I agree it is not as succinct as C++'s reflection syntax.
347.
by uecker 5mo ago
In practice it is written like like this: #define MY_ENUM(x) x(MY_A) x(MY_B) x(MY_C) enum my_enum { MY_ENUM(ENUM_ENTRIES) }; static const char *my_enum_names[] = { MY_ENUM(ENUM_NAMES) }; but one could also make it even more comp
348.
by uecker 5mo ago
In practice, I see people write very performance C code where it matters, while moving on quickly where it does not. C++ code is often highly templated with annoying compile times, but still often slow because it still does not use the righ
349.
by uecker 5mo ago
C is not slow compared to C++. C++ compilation time are slow though.
350.
by uecker 5mo ago
Are X macros awkward? I find them very straightforward and clear.
351.
by uecker 5mo ago
This does not make your comment above less wrong.
352.
by uecker 5mo ago
Nowadays you would work in git and then you would be able to easily detect any discrepancy between the upstream tar ball and the upstream source imported via git. But yes, better support for securing more of the process is needed.
353.
by uecker 6mo ago
Typo-squatting attacks are more of an issue for non-curated software collections, not so much for Debian. If you use npm or cargo or similar, then you have indeed far bigger worries. Compromising the source has the disadvantage for the atta
354.
by uecker 6mo ago
If your compiler (or other tool or automatic build environment) is compromised and inserts a backdoor in the binary during building, the fact that you need to hold a key while signing or not is completely irrelevant. git log and build logs
355.
by uecker 6mo ago
A hardware key does not help if the developer's machine is compromised, as there is no change to understand what is signed anymore, or do you think the hardware key will show all the source code on its little display before signing? W
356.
by uecker 6mo ago
An attack would be far easier without reproducible packages. One could upload a compromised binary to debian by becoming a debian developer, blackmail a debian developer to so, or compromise the computer of a debian developer or the distrib
357.
by uecker 6mo ago
This is a huge achievement for Debian and the free software world. It took a while though until this was understood. In 2007 when pointing out on debian-devel that this is needed, I was still told what huge waste of time this would be. And
358.
by uecker 6mo ago
Well, I would say google "might" be counting differently or have huge bias.
359.
by uecker 6mo ago
It is impossible to interpret this number (271) without looking into details. People certainly found plenty of memory safety and others bugs in Rust projects in the past, so I do not understand you claim that there too few to find any. Curl
360.
by uecker 6mo ago
There exist memory safety bugs in Rust projects, so you will find them. Or maybe not with AI, as there is not enough training data? The 70% number google claims is either BS or google-specific as other projects reported far lower numbers.

More ›