Newest at the top
| 2025-02-26 20:29:33 +0100 | <monochrom> | Yeah I think I saw the Linux Itanium-based one. |
| 2025-02-26 20:28:43 +0100 | <EvanR> | it might seem intuitive that structs which differ by being a prefix of another is compatible but its not |
| 2025-02-26 20:28:03 +0100 | <EvanR> | casting a pointer to an incompatible type is undefined behavior |
| 2025-02-26 20:27:15 +0100 | <dolio> | I don't really feel like finding it, though. |
| 2025-02-26 20:27:03 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 245 seconds) |
| 2025-02-26 20:26:57 +0100 | <EvanR> | I was also pretty sure xD |
| 2025-02-26 20:26:43 +0100 | <dolio> | No, that part is in there, I'm pretty sure. |
| 2025-02-26 20:26:35 +0100 | <EvanR> | it's a folk practice |
| 2025-02-26 20:26:24 +0100 | <EvanR> | dolio, the rudimentary subtyping with structs isn't actually guaranteed to work if all you have is a C standard |
| 2025-02-26 20:24:57 +0100 | <TMA> | and the list goes on and on and on |
| 2025-02-26 20:24:47 +0100 | <TMA> | clang and gcc use somewhat different ABI for C++ |
| 2025-02-26 20:24:19 +0100 | <TMA> | on Windows Microsoft uses its own |
| 2025-02-26 20:24:05 +0100 | <TMA> | on linux they use a derivative of the Itanium ABI |
| 2025-02-26 20:23:49 +0100 | <monochrom> | I guess there is an xkcd for that. |
| 2025-02-26 20:23:40 +0100 | <monochrom> | yikes oh well heh |
| 2025-02-26 20:23:11 +0100 | <TMA> | monochrom: if only that was so straightforward. there are multiple ABI standards for x86 and x86_64 |
| 2025-02-26 20:21:41 +0100 | <TMA> | tomsmeding: some ABI prescribe layout of structs. others don't |
| 2025-02-26 20:19:45 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-02-26 20:19:44 +0100 | <TMA> | the requirement says only "be consistent when there are multiple compilation units" |
| 2025-02-26 20:19:06 +0100 | <TMA> | or even offsetof(struct S, c1) == 0, offsetof(struct S, i) == 1, offsetof(struct S, c2) == 5 |
| 2025-02-26 20:18:41 +0100 | <tomsmeding> | oh fair |
| 2025-02-26 20:18:19 +0100 | <TMA> | or it might be offsetof(struct S, c1) == 0, offsetof(struct S, i) == 4, offsetof(struct S, c2) == 8 |
| 2025-02-26 20:17:59 +0100 | <TMA> | for example a struct S { char c1; int i; char c2; } s; might be organized such that offsetof(struct S, c1) == 0, offsetof(struct S, i) == 4, offsetof(struct S, c2) == 1 |
| 2025-02-26 20:17:39 +0100 | <tomsmeding> | those ABIs say something about _structs_? |
| 2025-02-26 20:17:06 +0100 | <monochrom> | I am too lazy to check the C standard. But I want to point out that there is one x86 ABI standard and one x64 ABI standard that C compilers targetting those platforms will comply to, and the two ABI standards are very specific about structs, function call arguments, etc., so that various C compilers, nay, various languages, can interoperate when they are on the same platform. |
| 2025-02-26 20:15:59 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-02-26 20:14:34 +0100 | <TMA> | C standard does not prescribe the conforming implementation ("compiler") to be interoperable with any other compiler, or even with itself with a different set of flags/options. |
| 2025-02-26 20:13:54 +0100 | <tomsmeding> | by induction, that second requirement fixes the ordering completely |
| 2025-02-26 20:13:13 +0100 | <TMA> | It also needs to make two structs that share some prefix of the fields be compatible. (So struct A { int * p; char c; int i; double d; } and struct B { int * p; char c; int i; char * s; } need to share the memory locations od p, c and i;) |
| 2025-02-26 20:10:40 +0100 | <geekosaur> | in fact, there's a decent number of restrictions in Haskell (GHC or otherwise) which come from "we can't teach the linker how Haskell works" |
| 2025-02-26 20:10:33 +0100 | <TMA> | C standard leaves many things unspecified. A conforming implementation must make the same struct that is used in different compilation units translate in a way that makes both compilation units able to access it. |
| 2025-02-26 20:09:27 +0100 | <geekosaur> | but that means the inker needs to be a lot smarter |
| 2025-02-26 20:09:13 +0100 | <geekosaur> | I think it can be inferred from pointers, presuming such exist |
| 2025-02-26 20:07:16 +0100 | <tomsmeding> | (in fact it doesn't reveal reorderings _at all_. :P) |
| 2025-02-26 20:06:53 +0100 | <geekosaur> | (GHC gets around this by carrying extra information in `.hi` files) |
| 2025-02-26 20:06:30 +0100 | <geekosaur> | there is also what is exposed in object files and include files, which is not all that the original compiler knows and in particular doesn't reveal reorderings very well |
| 2025-02-26 20:06:10 +0100 | <tomsmeding> | and simultaneously more than you'd like. :P |
| 2025-02-26 20:05:58 +0100 | <tomsmeding> | if things are as usual in C land, then probably very little |
| 2025-02-26 20:05:27 +0100 | <dolio> | Well, yeah, I'm not exactly sure what all you can get away with within the standard. |
| 2025-02-26 20:04:55 +0100 | <tomsmeding> | Maybe some of this is not possible in "standard C" and only in conventional C. |
| 2025-02-26 20:04:17 +0100 | <tomsmeding> | and perhaps that other code in the shared library can use prefixes of _your_ structs! |
| 2025-02-26 20:03:53 +0100 | <tomsmeding> | so if the compiler reorders things, it'll have to do so deterministically and based only (I think?) on the struct definition itself |
| 2025-02-26 20:03:30 +0100 | <tomsmeding> | it's expected that you can compile some code to a shared library with compiler X, then link that into some other C code also compiled with X, and have the structs be compatible |
| 2025-02-26 20:03:03 +0100 | <tomsmeding> | if you can see all code, then you can indeed pull such tricks. But given that this is C, as soon as you pull in other (already-compiled) libraries and give them references to your structs _somehow_, or if you include some assembly code, or if you muck with pointers in the right way, I'd expect it gets very hard to change the encoding of structs |
| 2025-02-26 20:02:47 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) |
| 2025-02-26 20:02:01 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-02-26 20:01:53 +0100 | <tomsmeding> | though LTO exists |
| 2025-02-26 20:01:49 +0100 | <dolio> | I didn't say it was easy. :รพ |
| 2025-02-26 20:01:45 +0100 | <tomsmeding> | C compilers are conventionally very translation-unit-oriented :) |
| 2025-02-26 20:01:33 +0100 | <dolio> | Yeah. |