Newest at the top
| 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.) |
| 2024-11-05 20:11:40 +0100 | <tomsmeding> | (though I found it in C11 -- apparently the section numbering didn't change significantly from C11 to C18?) |
| 2024-11-05 20:11:20 +0100 | <tomsmeding> | we found it :) |
| 2024-11-05 20:11:12 +0100 | <monochrom> | BTW the unsigned modulo rule is (in C 2018) 6.2.5 item 9. |
| 2024-11-05 20:08:31 +0100 | <tomsmeding> | well, I guess index arithmetic could be unsigned integer arithmetic, but it's _signed_ integer arithmetic in practice in C |
| 2024-11-05 20:08:10 +0100 | <tomsmeding> | and people have array accesses in the dependency chain (how is that called again?) in hot loops, but usually not unsigned integer arithmetic :p |
| 2024-11-05 20:07:57 +0100 | <Rembane> | Good point. Then that instruction shouldn't be too heavy. |
| 2024-11-05 20:07:31 +0100 | <tomsmeding> | bounds checking typically involves more than 1 instruction, perhaps even a memory load for the size of the array |
| 2024-11-05 20:06:46 +0100 | <tomsmeding> | a very predictable branch, at that, so while it does increase your code size and increases the pressure on the branch predictor cache, it won't be _too_ egregious |
| 2024-11-05 20:06:10 +0100 | <tomsmeding> | x86 has an overflow (! naming ._.) flag that you can check for with a single conditional branch instruction |
| 2024-11-05 20:06:04 +0100 | <Rembane> | tomsmeding: Sweet. Maybe I have mixed it up with actually doing bounds checking before the fact. |
| 2024-11-05 20:05:55 +0100 | ZLima12 | (~zlima12@user/meow/ZLima12) ZLima12 |
| 2024-11-05 20:05:47 +0100 | <tomsmeding> | Rembane: depends on the cpu, I think |
| 2024-11-05 20:05:35 +0100 | <Rembane> | tomsmeding: But IIRC that's super slow. |
| 2024-11-05 20:05:31 +0100 | <Rembane> | tomsmeding: I think I'm more of the trapping school. |