Newest at the top
| 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 |
| 2025-02-26 19:54:10 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) (Read error: Connection reset by peer) |
| 2025-02-26 19:54:06 +0100 | jespada | (~jespada@2800:a4:230f:300:5891:d568:1db3:6726) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-02-26 19:53:47 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-02-26 19:53:22 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-02-26 19:50:58 +0100 | tv | (~tv@user/tv) tv |
| 2025-02-26 19:49:17 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-26 19:42:50 +0100 | fun-safe-math | (~fun-safe-@2601:1c2:1b7f:801f:26d6:a094:aa3b:66cd) fun-safe-math |
| 2025-02-26 19:42:45 +0100 | zungi | (~tory@user/andrewchawk) andrewchawk |
| 2025-02-26 19:42:23 +0100 | zungi | (~tory@user/andrewchawk) (Remote host closed the connection) |
| 2025-02-26 19:41:35 +0100 | fun-safe-math | (~fun-safe-@2601:1c2:1b7f:801f:6422:3799:4fbd:4a99) (Quit: No Ping reply in 180 seconds.) |
| 2025-02-26 19:40:58 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-02-26 19:39:24 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2025-02-26 19:37:28 +0100 | Everything | (~Everythin@46-133-48-141.mobile.vf-ua.net) Everything |
| 2025-02-26 19:35:30 +0100 | Everything | (~Everythin@46-133-48-141.mobile.vf-ua.net) (Quit: leaving) |
| 2025-02-26 19:29:01 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2025-02-26 19:28:47 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f80fcc6edffa39079b3.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2025-02-26 19:26:47 +0100 | <dolio> | I guess it's possible you could accomplish that while doing some reordering, but it'd be pretty complicated to pull off. |
| 2025-02-26 19:26:22 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-02-26 19:25:44 +0100 | <mauke> | yes, the "common prefix" hack |
| 2025-02-26 19:25:33 +0100 | <dolio> | They need to be in order because you're allowed to do a rudimentary sort of subtyping on structs, I think. |
| 2025-02-26 19:24:51 +0100 | <mauke> | (public:, private:, protected:) |
| 2025-02-26 19:24:43 +0100 | <c_wraith> | ah. Silly language. Make no guarantees about their relative offsets, but require them to be in order. |
| 2025-02-26 19:24:37 +0100 | <mauke> | C++ compilers are allowed to re-order segments separated by visibility markers, but that's it |
| 2025-02-26 19:24:37 +0100 | califax | (~califax@user/califx) califx |
| 2025-02-26 19:23:54 +0100 | <mauke> | nope |
| 2025-02-26 19:23:46 +0100 | <c_wraith> | I thought compilers were allowed to re-order members |
| 2025-02-26 19:22:32 +0100 | tv | (~tv@user/tv) (Read error: Connection reset by peer) |
| 2025-02-26 19:22:32 +0100 | <mauke> | the idea is to declare a struct with a char as its first member (which throws off the alignment of the second member) and then check how much padding the C compiler inserted before the second member |
| 2025-02-26 19:20:51 +0100 | <hseg> | yeah, the #alignment macro, looking at the hsc2hs docs |
| 2025-02-26 19:20:17 +0100 | <mauke> | nowadays it's built into hsc2hs, I believe |
| 2025-02-26 19:20:08 +0100 | <mauke> | computes the required alignment of a given type (by asking the C compiler) |
| 2025-02-26 19:19:32 +0100 | <hseg> | what does that alignment macro do? |
| 2025-02-26 19:19:15 +0100 | <hseg> | I see the package is used by darcs and idris, loos like a safe dependency |
| 2025-02-26 19:19:05 +0100 | <mauke> | oh hey, that's my alignment macro! I invented that |