uecker

4 ms·

31.
by uecker 17d 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
32.
by uecker 17d 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
33.
by uecker 17d ago
Thanks! This is cool. In need to do some reading...
34.
by uecker 17d 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
35.
by uecker 17d ago
No, why? It simply means that the arguments are in different registers.
36.
by uecker 17d ago
This is not my experience.
37.
by uecker 17d ago
Thanks, but now you should explain why you think this slight (and well understood) difference in calling convention is a rather important difference.
38.
by uecker 17d ago
Well, these things were discussed in previous articles the previous one is linked at the very top. This one explains how you can avoid the use of trampolines in GCC 17: https://uecker.codeberg.page/2026-07-14.html The docum
39.
by uecker 17d ago
I am not the only one who wants nested functions and function literals (lambdas) in C (as in basically any other modern language) and I explained every time that trampolines are not needed for this. It is frankly quite tiring that every tim
40.
by uecker 17d ago
I think you should read my article ;-) ... because the point is that nested functions in C are basically implemented in a very similar way as C++'s lambdas with "unnameable types" a frontend detail. The idea that "closur
41.
by uecker 18d ago
If I look at actual incidence involving memory safety issues compared to supply chain issues in general, it is the later which is much a higher risk to me. And yes, there were successful supply chain attacks on Rust developers, even just re
42.
by uecker 18d ago
This is still not type checking, it accepts whenever the bit pattern is a valid for floating point even when it originally was used as another type.
43.
by uecker 19d ago
Can one really derive classical GR completely from a QFT of a spin-2 field? Or only a linear approximation?
44.
by uecker 19d ago
For "strongly typed" I would expect some type checking.
45.
by uecker 19d ago
Well, I was leaving C++ for C. I found this unburdened my mind from quite a lot of distracting complexity. For this reason, I am also not really tempted by Rust.
46.
by uecker 19d ago
The idea that processor evolution is blocked by the need to run C code is wrong. We had many alternative designs, both for languages and also for processors. They were simply not successful. I still remember the pain of segmented memory in
47.
by uecker 19d ago
GCC is usually ahead in terms of new C features.
48.
by uecker 19d ago
Yes, I have much less complaints about the content of this paper, except for the PDP-11 meme aspect.
49.
by uecker 20d ago
Chisnall's article. A lot of the general criticism would still apply if you replace "PDP-11" with "von Neumann architecture" which makes the whole thing a bit weird. But also many specific comments about C are bit
50.
by uecker 20d ago
Note that IMHO there are quite a few things incorrect or misleading in this article.
51.
by uecker 20d ago
I do not disagree with the point that some superficial aspects are inspired by the PDP-11, I disagree with that this has anything to do with the fundamentals of computing architecture. It would also completely contradict the whole idea that
52.
by uecker 20d ago
I do not think that pre- and postincrement operator being inspired by PDP-11 has anything to with fundamental system design questions.
53.
by uecker 20d ago
I think this PDP-11 meme is quite misleading. There is nothing really in the C programming model specific to the PDP-11 and C was used on systems much weirder than a PDP-11. C is also very successfully the basis of many parallel programs ru
54.
Implementation of GCC's Nested Functions (vs. C++ Lambdas)(uecker.codeberg.page)
77 points by uecker 21d ago|42 comments
55.
by uecker 22d ago
But "the generated types will be isomorphic but incompatible" is right. It is ok if you have lib_a.c and lib_b.c because these are two separate translation units. But this only works if both of these libraries use the list type i
56.
by uecker 22d ago
No, you are right, but it is not "in separate files" but "translation units". Two distinct list(int) from two different libraries need to be compatible when used together, which means you would include the header of tho
57.
by uecker 23d ago
No, any tagless type is unique, so neither A and B nor list_of_A and list_of_B are compatible. This is what I like to fix in C2y outside of typedefs (and it would really help if you file wishlist bugs with compilers if you agree).
58.
by uecker 23d ago
You are right that it is not perfect, but it is fine for me and usability is not worse than for C++. I use the rule that only identifiers (typedef names) can be passed. Then the macro can synthesize a tag and list type is then compatible be
59.
by uecker 23d ago
I do not think a type-safe macro-generated list in C is any more awkward to implement or inferior to a C++ template version. The issue is more than there is no standardized version directly available except perhaps the old BSD ones and tho
60.
by uecker 26d ago
While I think this is a good idea, I think this the importance is massively exaggerated. Not everything in other languages is unsafe, there are also different features one can distinguish where some are safe and some are not. It is not a

More ›