Newest at the top
| 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. |
| 2025-02-26 20:01:26 +0100 | <tomsmeding> | that would need to be a full-program transformation |
| 2025-02-26 20:01:07 +0100 | <dolio> | I once read about an OCaml implementation using the statically available type information to calculate flat array representations of every 'object' type, even though you can use them as arbitrary subtypes. |
| 2025-02-26 19:59:42 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 246 seconds) |
| 2025-02-26 19:59:38 +0100 | <dolio> | Certainly if you don't do something else tricky, that's true. |
| 2025-02-26 19:59:06 +0100 | ChanServ | +v haskellbridge |
| 2025-02-26 19:59:06 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) hackager |
| 2025-02-26 19:57:28 +0100 | <dolio> | I don't know. |
| 2025-02-26 19:56:56 +0100 | <tomsmeding> | dolio: surely you could use all possible prefixes of a struct? Then the ordering ends up fixed |
| 2025-02-26 19:54:57 +0100 | jespada | (~jespada@2800:a4:230f:300:5891:d568:1db3:6726) jespada |