Newest at the top
| 2024-11-05 20:33:51 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-11-05 20:33:46 +0100 | <monochrom> | By 6.2.6.2 item 4, you get much guarantees by using memcpy(&dst, &src, the_size). |
| 2024-11-05 20:33:25 +0100 | <dolio> | There might be special cases where unions like that are defined to work. But not in general, I think. |
| 2024-11-05 20:33:20 +0100 | <tomsmeding> | I know people are doing this precisely to evade the "pointer casting is not necessarily defined" thing |
| 2024-11-05 20:33:04 +0100 | <tomsmeding> | dolio: oh isn't there? That would be funny |
| 2024-11-05 20:32:53 +0100 | <tomsmeding> | er, *(int32_t*)&x |
| 2024-11-05 20:32:38 +0100 | <tomsmeding> | int32_t float_to_int_wrong(float x) { return *(int*)&x; } |
| 2024-11-05 20:32:26 +0100 | hamster | (~ham@user/ham) (Read error: Connection reset by peer) |
| 2024-11-05 20:32:25 +0100 | ham2 | (~ham@user/ham) ham |
| 2024-11-05 20:32:21 +0100 | <tomsmeding> | as opposed to what naive C enthousiasts might write: |
| 2024-11-05 20:32:04 +0100 | <tomsmeding> | int32_t float_to_int(float x) { union { int32_t i; float f; } u; u.f = x; return u.i; } |
| 2024-11-05 20:31:39 +0100 | <tomsmeding> | no it's not a general casting trick, it is essentially c++'s reinterpret_cast |
| 2024-11-05 20:31:23 +0100 | <dolio> | Also, I think there's no guarantee that writing to one field of a union and reading from a different field actually works. |
| 2024-11-05 20:31:12 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2024-11-05 20:31:01 +0100 | <dolio> | What is cast-through-a-union? I'd have to look, but I wouldn't necessarily expect a pointer to a union to be guaranteed to have the same address space as a pointer to either of its components. |
| 2024-11-05 20:27:21 +0100 | zmt01 | (~zmt00@user/zmt00) (Ping timeout: 276 seconds) |
| 2024-11-05 20:25:40 +0100 | <tomsmeding> | hence undefined signed integer overflow |
| 2024-11-05 20:25:29 +0100 | <tomsmeding> | because that, supposedly, _is_ defined (or so I was told) |
| 2024-11-05 20:25:29 +0100 | <dolio> | Or exact representations of all the integer types. |
| 2024-11-05 20:25:14 +0100 | <tomsmeding> | hence the cast-through-a-union dance |
| 2024-11-05 20:25:13 +0100 | emma-underscores | (~underscor@pool-108-54-214-254.nycmny.fios.verizon.net) (Quit: WeeChat 4.4.3) |
| 2024-11-05 20:24:42 +0100 | <dolio> | Yeah. There's no guarantee that differen't types inhabit the same memory, so things like casting between different pointer types isn't necessarily kosher. |
| 2024-11-05 20:23:27 +0100 | swamp_ | (~zmt00@user/zmt00) zmt00 |
| 2024-11-05 20:23:20 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2024-11-05 20:23:04 +0100 | <tomsmeding> | due to wanting to support platforms with very unusual (or historical) pointer representations, etc. |
| 2024-11-05 20:22:19 +0100 | tomsmeding | was told at some point that the C standard actually guarantees very little about implementation details |
| 2024-11-05 20:22:04 +0100 | hgolden_ | (~hgolden@169.150.203.36) (Ping timeout: 260 seconds) |
| 2024-11-05 20:21:35 +0100 | <dolio> | It was some complaint that the Haskell standard doesn't nail down the exact implementation behavior of enough things. But C really doesn't, either, for a lot of things if you actually look. |
| 2024-11-05 20:19:42 +0100 | <monochrom> | Both extremes exists. There are also people who unconditionally claim "UB" and they are sometimes wrong. :) |
| 2024-11-05 20:19:26 +0100 | hgolden__ | (~hgolden@146.70.173.165) hgolden |
| 2024-11-05 20:18:13 +0100 | flounders | (~flounders@173.246.200.74) flounders |
| 2024-11-05 20:17:54 +0100 | <tomsmeding> | perhaps the authors of the 701-page document can feel self-satisfied with their volume of output, and therewith call the thing "glorious" |
| 2024-11-05 20:16:52 +0100 | <tomsmeding> | glorious? |
| 2024-11-05 20:16:46 +0100 | <dolio> | vs. Haskell. |
| 2024-11-05 20:16:30 +0100 | <dolio> | I mainly wanted it to go through and nitpick all the ways in which the supposedly glorious C standard wasn't as well defined as someone here was presenting it as. |
| 2024-11-05 20:15:48 +0100 | <tomsmeding> | <insert further rant about pointlessness of charging for a _standard_> |
| 2024-11-05 20:15:27 +0100 | <tomsmeding> | the draft _becomes_ the de facto actual version |
| 2024-11-05 20:15:19 +0100 | <tomsmeding> | they are enough for everyone by plain stupidity of charging for the actual version |
| 2024-11-05 20:15:01 +0100 | <dolio> | Ah, well, drafts are good enough for me. |
| 2024-11-05 20:14:43 +0100 | <tomsmeding> | ISO won't even sell me C11 any more -.- |
| 2024-11-05 20:14:34 +0100 | <tomsmeding> | drafts are free indeed, I have never seen anyone before claim that a _final_ version was free |
| 2024-11-05 20:13:47 +0100 | <monochrom> | Is it a draft? |
| 2024-11-05 20:13:34 +0100 | <tomsmeding> | where did you get it |
| 2024-11-05 20:13:24 +0100 | <dolio> | I'm not going to pay for something like that. |
| 2024-11-05 20:13:23 +0100 | <tomsmeding> | O.o |
| 2024-11-05 20:13:16 +0100 | <dolio> | Yeah, the one I have was free. |
| 2024-11-05 20:13:07 +0100 | <tomsmeding> | are any free? |
| 2024-11-05 20:12:56 +0100 | <dolio> | I assume 2018 still isn't free? |
| 2024-11-05 20:12:26 +0100 | <tomsmeding> | er -- I said "9.2.5 paragraph 9" but that was a typo/thinko, should have been 6.2.5 par 9, clearly |
| 2024-11-05 20:11:59 +0100 | <monochrom> | Hrm maybe I should also download the C11 and other versions. (University grants access.) |