Notices by equinox (equinox@chaos.social)

@mirabilos sure, if that's your choice then that's your choice.

I have written code for AF_ALG and I run IPsec. (without ESNs, because that's the default in StrongSwan, and I haven't had reason to worry about rekeying.)

I know who @dalias is and I greatly respect them for their work on musl. But I'll stick with my opinion until someone claims at least the same experience level as I have. Maybe that's dalias, maybe not, idk their skills on this.

@dalias @pinskia now *this* one (nested functions being antifeatures) I do fully agree with.

It just happens to kneecap a non-UB variant of this particular hack, which, yeah, wouldn't need the trampoline, just to "somehow emit another function from the middle of a function".

I never thought about putting the same "cast" in a compound literal. That would make it more portable, except of course the UB is still the same.

(Wouldn't help my work space, GCC/clang tied in a million other places…)

@dalias @pinskia I'm sorry but I'll prioritize bug-free (or rather bug-less) code now over theoretical future achievements. And I don't target theoretical ABIs either.

But I *do* agree with your point and probably wouldn't do this in a library-type project with a different audience. The software I work on supports Linux and *BSD with GCC and clang. If making assumptions based on that gets me safety advantages elsewhere, I will abso-fucking-lutely take them. Actual benefit > theoretical benefit.

@dalias @pinskia the really sad thing is that if clang had nested functions, that's what that macro would contain, i.e. a tiny wrapper that does the cast.

The entire thing, if you use ({ }) is GCC/clang only already, anyway. But narrowing it further to GCC-only is a constraint I *can't* apply.

@dalias @pinskia interesting tech. I'll make a note of it, though unfortunately a Windows-only tool is out of reach for anything I'm doing.

@dalias @pinskia if you truly think I'm doing this for "style points" you are sorely mistaken. This is about catching _actual_ bugs, and not even rare ones, you can typo your way into this.

Does that tooling you're describing there actually exist? I'm not aware of any. It'd certainly solve the same problem, … except worse, since you actually have to run the code and hit the location.

(and, of course, this tooling wouldn't be ABI compatible with anything existing)

@dalias @pinskia K this was kinda what I meant with "general uncastability of pointers in C" but I didn't really say what I meant so that's on me.

Either way my answer stays the same, I deeply don't care about this being UB. If calling a function through a prototype with a void pointer in place of a "higher" pointer makes some compiler generate incorrect code, that's on the compiler.

I don't live in a world that is only C; (ps)ABI exists and defines how these work.

@azonenberg @whitequark I thought the specs file is all you need for that (and it has worked for me so far, though I only do embedded stuff for fun once in a while)

It seemed mostly an issue of picking the correct linker scripts and crt*.o files where necessary, and those are in the .specs…

"How many GCC versions do you have installed?" — "Yes."

@whitequark does it sprout wings and a jet engine if you put it in airplane mode? 😂

@azonenberg @ariadne @astraleureka @lina it could be WAY worse:

when I got my fiber connection, I found for some reason it worked on OpenWRT but not my Debian box. After some digging, it turned out all DHCPv6 packets were 1514 byte Ethernet frames, regardless of IPv6/UDP content len.

Those extra bytes were a bug on the last-hop Cisco switches' DHCPv6 relay/inspection. Random snippets out of the switch's memory.

Including configs.

With other customer's *names and line IDs* (port descriptions)

@whitequark @azonenberg same here, with a twist: if anything the argument for us to move away from github would be that some github features just suck, e.g.:

- poor handling of backports
- poor trackability of PRs across edits/updates/rebases/… (gerrit style)
- repeated annoyances with external CI integration

But sum total the annoyances are below the social cost bar of justifying a move somewhere else.

@whitequark right. Ugh. I've used JS level perf tools before, but no clue about somehow getting useful perf (or trace) out of wasm…

Anyway I shall stop wasting your time, happy hacking & appreciate a whole bunch of your stuff! 😊

@whitequark ah. Huh. I would've expected *that* interface to not be all that different from what libusb does. Never looked at it, Firefox user 😅

@whitequark +9000 on "hard to debug this stuff", I've got a bunch of painful memories debugging around the URB layer & particularly when exactly what happens and why 😬

@whitequark for the USB bits specifically? I would've hoped USB were the bottleneck there, is it just increased request-response-repeat time/latency?

@r @whitequark @artemist longjmpQQ(), just selects a different multiple worlds quantum reality where the longjmp() already happened from the beginning.

@r @whitequark @artemist longjmpVE() that uses reverse van Eck phreaking to transfer program state to another nearby (potentially airgapped) computer and resumes execution there.

@whitequark I have seen "MIIM" maybe once or twice in my lifetime. Most I've seen, people just call it "c45_read" / "c22_read" and the like.

E.g. this bonanza: https://patchwork.kernel.org/project/netdevbpf/patch/20210331141755.126178-3-danilokrummrich@dk-develop.de/

Everything is MDIO.

@whitequark is there a { missing on the 3rd line or am I blind?