2025/02/26

Newest at the top

2025-02-26 20:58:10 +0100chiselfuse(~chiselfus@user/chiselfuse) (Remote host closed the connection)
2025-02-26 20:55:51 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-02-26 20:54:48 +0100zungi(~tory@user/andrewchawk) (Ping timeout: 264 seconds)
2025-02-26 20:54:34 +0100acidjnk_new(~acidjnk@p200300d6e7283f80fcc6edffa39079b3.dip0.t-ipconnect.de) acidjnk
2025-02-26 20:53:58 +0100pavonia(~user@user/siracusa) siracusa
2025-02-26 20:53:55 +0100weary-traveler(~user@user/user363627) (Remote host closed the connection)
2025-02-26 20:53:52 +0100 <dolio> Or use the variable length array at the end of a struct or something.
2025-02-26 20:52:29 +0100 <dolio> Yeah, I can't find that, so I guess that doesn't work. You have to put all your structures in a union.
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 +0100tccq(~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 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 265 seconds)
2025-02-26 20:39:19 +0100misterfish(~misterfis@84.53.85.146) misterfish
2025-02-26 20:37:21 +0100misterfish(~misterfis@84.53.85.146) (Ping timeout: 248 seconds)
2025-02-26 20:36:21 +0100sprotte24(~sprotte24@p200300d16f39ea0090c1360b4b7260ad.dip0.t-ipconnect.de)
2025-02-26 20:35:41 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-26 20:33:11 +0100Tuplanolla(~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 +0100ljdarj(~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 +0100Smiles(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 +0100Smiles(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.