Newest at the top
| 2025-02-26 20:51:46 +0100 | <EvanR> | I thought this was this "hope my struct defined the same way for the first 16 bytes" will work if pointer to it is casted, which is use in the sockets API |
| 2025-02-26 20:50:28 +0100 | <EvanR> | yes unions work |
| 2025-02-26 20:47:29 +0100 | tccq | (~user@user/tccq) (Remote host closed the connection) |
| 2025-02-26 20:45:37 +0100 | <dolio> | Normally if you access the portion of a union that wasn't used to build it, it's undefined behavior, but there's special dispensation for structs. |
| 2025-02-26 20:44:46 +0100 | <dolio> | I don't know if you can do it with pointers. But you can put all the structs with the same prefix in a union, and access the members of the prefix via any of the union disjuncts. |
| 2025-02-26 20:40:24 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 265 seconds) |
| 2025-02-26 20:39:19 +0100 | misterfish | (~misterfis@84.53.85.146) misterfish |
| 2025-02-26 20:37:21 +0100 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 248 seconds) |
| 2025-02-26 20:36:21 +0100 | sprotte24 | (~sprotte24@p200300d16f39ea0090c1360b4b7260ad.dip0.t-ipconnect.de) |
| 2025-02-26 20:35:41 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-26 20:33:11 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 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. |