| RAOF | Hm. | 06:55 |
|---|---|---|
| RAOF | You know, we *could* drop the `extern "C"` on our platform interfaces, and rely on `mir::SharedLibrary::load_function<>` to get the right symbol. | 06:56 |
| RAOF | That would prevent this bug, and also some UB. | 06:56 |
| RAOF | Hm. | 07:25 |
| RAOF | And it would only require relying on a little implementation-defined behaviour. | 07:25 |
| RAOF | I'm actually warming to the idea. | 07:25 |
| alan_g[m] | I'm curious what UB problem you're talking about, but I guess I'll find out when you PR a solution | 07:49 |
| RAOF | We throw exceptions across extern "C" boundaries. | 07:51 |
| * RAOF is not actually going to PR a solution to that, because it turns out to involve implementing an Itanium ABI name mangler. | 07:52 | |
| alan_g[m] | That one. Yeah. The approach I would take is to embed a hard-coded lookup table for the mangled names. But I've been sufficiently motivated | 08:09 |
| alan_g[m] | *not been | 08:11 |
| RAOF | A function-only name mangler would not be a particularly terrible task, but 🤷♀️. | 08:13 |
| alan_g[m] | A name mangler is really something for std:: | 08:14 |
| RAOF | I mean, yes. | 08:14 |
| RAOF | Although it's implementation defined, so the standard wouldn't really have a lot to say about it. | 08:14 |
| alan_g[m] | That's the point: the standard can say "do what the implementation does" | 08:15 |
| RAOF | type_info::name() gets you everything but what we want, too :) | 08:15 |
| RAOF | Yeah, it'd totally be a useful addition to std:: | 08:15 |
| RAOF | Anyway! Today: | 08:22 |
| RAOF | * (very nearly) Plumbed "only load RenderingPlatforms that can drive at least one display" probing through | 08:22 |
| RAOF | * Did a little investigation into how to make our symbol loading nicer, particularly catching errors at compile time (prompted by the probing change causing segfaults due to a signature change). | 08:22 |
| RAOF | * Decided that it's tractable, but not for now 😉 | 08:22 |
| RAOF | Oh, no. | 08:22 |
| RAOF | It's actually even more tractable, isn't it? | 08:22 |
| RAOF | type_info::name() gives us everything but what we want, but string concatenation should be able to take us the rest of the way? | 08:23 |
| RAOF | Damn. | 08:25 |
| RAOF | Now I'll think about it more 🤦♀️ | 08:25 |
| alan_g[m] | Relying on unspecified behaviour isn't a whole lot better than relying on undefined behaviour. Just because we know g++/clang++ return the mangled name doesn't make it safe | 08:41 |
| alan_g[m] | Damn! You got me thinking about it again. Mangling correctly is hard without the compilation context (it needs to know about macros, typedefs and using declarations - and, for some cases, the current function name). It is probably possible from the clang AST, but that's, at best, an extra compilation pass. | 09:00 |
| RAOF | Right, but we don't need a general-purpose mangler; we just need to be able to mangle free-functions not in a namespace. | 09:09 |
| alan_g[m] | We actually only need a few known functions - a lookup table will suffice | 09:11 |
| RAOF | That's true. | 09:12 |
| RAOF | We could also automate that in the build process, right? Build an object exposing that symbol, read the mangled name out of objdump. | 09:13 |
| RAOF | Or, because we only have a list of like 5 symbols, not bother. | 09:14 |
| alan_g[m] | Or, because throwing exceptions through extern "C" works for the implementations we use, not bother | 09:16 |
| alan_g[m] | Today: | 16:48 |
| alan_g[m] | * Got a "working" spike of drag-n-drop | 16:48 |
| alan_g[m] | Note: Monday is a public holiday here, and I'm taking Tuesday as vacation | 16:48 |
| sophie-w | Oops, I've been forgetting to do my updates. | 16:54 |
| sophie-w | Yesterday and the day before: | 16:54 |
| sophie-w | - worked on the issue of gedit not coming up in mir-ci, and eventually decided the most straightforward way to fix this was to use pluma editor instead: https://github.com/MirServer/mir-ci/pull/35 | 16:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!