uecker

5 ms·

61.
by uecker 1mo ago
The point is that it can always be adapted to a common wide pointer type, which C could provide as a standard. C++ already has a solution for this on their ide: std::function(_ref).
62.
by uecker 1mo ago
You can stuff it into something such as std::function_ref which erases the Voldemort type and then it can be dynamically called without needing templates. And this could be from C or other languages if only there was a common type in C we c
63.
by uecker 1mo ago
I does not need to be embedded. I just need a pointer to it.
64.
by uecker 1mo ago
Except doing this manually does not allow me to directly call a C++ lambda, a Go closure, an Ada closure etc which I can not even express in C. So compatibility can not become worse, it is already maximally bad. And even where you can build
65.
by uecker 1mo ago
At the moment we can not call nested functions or other things from other language from C, which is a pretty big hole in our interoperability story. I do not see why we need to make any design decision to specify object layout, we simply ne
66.
by uecker 1mo ago
This is why I want to have such a feature in C. It would be extremely useful for language interoperability. But because ISA was mentioned, x86 does indeed even have native support for this: https://devblogs.microsoft.com/old
67.
by uecker 1mo ago
Thanks. Sigils fixed (may take a couple of minutes).
68.
Indirect Calling of Nested Functions on GCC Without Executable Stack(uecker.codeberg.page)
75 points by uecker 1mo ago|62 comments
69.
by uecker 1mo ago
Yes, this makes more sense as you at least collapse the third dimensions, but I would assume this formula is still faster when implemented efficiently.
70.
by uecker 2mo ago
I really hope nobody computes the volume by rendering in 3D and counting pixels.
71.
by uecker 2mo ago
My point was not that those are standards-compliant, but that the use of the GCC extensions is not the primary cause of those examples being unreadable. (which seemed to be the point the person I replied to was making - and I disagree with
72.
by uecker 2mo ago
I do not think this is a "mistake". This is the result of different priorities. Rust has done nothing to make me safer (although I agree that memory safety is desirable) and the supply chain issues make me less safe. Still parts
73.
by uecker 2mo ago
I don't think this is really about GCC extensions (or obsolete language modes) rather than using the flexibility of the syntax to write things in a confusing way. The first is simply K&R definitions + strange formatting.
74.
by uecker 2mo ago
What is hard to implement about it? I implemented in my toy compiler without a major problem. x86_64 ABI for passing structures or C's initializers were harder to implement. Many other programming languages such as Ada have VLAs on the
75.
by uecker 2mo ago
sorry you are just ranting. I was asking for specific details. The documentation for TLS seems this: https://www.uclibc.org/docs/tls.pdf
76.
by uecker 2mo ago
There is definitely random hate against this feature from some sides. But no good arguments as far as I can see.
77.
by uecker 2mo ago
According to people which were there, things were made optional in C11 because C99 was slowly adopted, not because there were any concerns with the feature.
78.
by uecker 2mo ago
Thanks, I need to dig into this more. But I still not convinced there is a real issue here. Of course different infrastructure needs to exist for different feature. What exactly is the underlying issue with thread_local in your specific sce
79.
by uecker 2mo ago
It could be fine if you care only about free-software desktop users, and not Google's propriety platform and hyperscalers.
80.
by uecker 2mo ago
Sorry, again this too vague for me. What is the exact problem with atomics and thread_local in C that would make the ABI dependent on a specific version of glibc? I know the ABI is not just calling convention and e.g. for atomics may invol
81.
by uecker 2mo ago
Sorry, can you be more specific. I do not understand what the problem is. If Musl does not implement support for the ABI, this would be a musl problem?
82.
by uecker 2mo ago
It depends on functions defined in a standardized ABI.
83.
by uecker 2mo ago
I am not really sure. For ld.so and libc.so I may believe this. The C ABI is very stable, and if you use a new symbol from a newer glibc, you certainly depend on it, but this can also be avoided. In any case, I do not see what is fundament
84.
by uecker 2mo ago
I can't comment on the C++, I can imagine there plenty of issues, but for C I don't see this. You need some libc if you compile with gcc, but this generally does not introduce a hard version dependency on the specific version (the
85.
by uecker 2mo ago
In what sense do binary interpreter / loader, GCC compiler, C library and system C/C++ ABI dependent on each other? I have certainly mixed different versions of all these components without problems so far.
86.
by uecker 2mo ago
There are certainly not on the chopping block and were standardized in C99. alloca will certainly never be standardized.
87.
by uecker 2mo ago
Why is that?
88.
by uecker 2mo ago
Nobody should use alloca. If you must allocate a buffer on the stack, use a VLA, which is standardized, has proper scope-bound lifetimes, and a type that remembers the exact size. Yes, I know MSVC does not upport it. Don't use this com
89.
by uecker 2mo ago
Regarding function syntax in C++: GCC's C++ frontend does not support nested functions. But more importantly, even if it did, I do not think there would be any conflict at all. While lambdas are lowered to function objects with an uniq
90.
by uecker 2mo ago
GCC's nested functions can also capture variables by reference. A closure combines the function with the environment which is essentially what my wide pointer is that contains the static chain that points to the environment. But for f

More ›