Newest at the top
| 2024-11-05 22:07:21 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-05 22:05:29 +0100 | CoolMa7 | (~CoolMa7@ip5f5b8957.dynamic.kabel-deutschland.de) CoolMa7 |
| 2024-11-05 21:59:21 +0100 | Guest7 | (~Guest7@137.79.192.219) |
| 2024-11-05 21:59:02 +0100 | Guest7 | (~Guest7@137.79.192.219) (Remote host closed the connection) |
| 2024-11-05 21:56:38 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-11-05 21:51:59 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-05 21:44:42 +0100 | sprotte24 | (~sprotte24@134.245.44.86) (Ping timeout: 276 seconds) |
| 2024-11-05 21:41:27 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-11-05 21:40:37 +0100 | sprotte24_ | (~sprotte24@p200300d16f3f2c00b0d50a9d74dbbab9.dip0.t-ipconnect.de) |
| 2024-11-05 21:40:36 +0100 | <monochrom> | But they also have old ones esp. c11 and c99 if you still want them. |
| 2024-11-05 21:40:11 +0100 | <monochrom> | Right they haven't had 2024 yet, only 2018 for now. |
| 2024-11-05 21:39:51 +0100 | <monochrom> | I don't actually know. |
| 2024-11-05 21:39:47 +0100 | <tomsmeding> | can't find anything for "9899:2024" in the title field, supposedly that should have found it |
| 2024-11-05 21:39:08 +0100 | <monochrom> | Counterexample to the fundamental theorem of DNS "DNS is suffix-closed". >:) |
| 2024-11-05 21:38:58 +0100 | <tomsmeding> | oh this seems to be a subscription manager that your university contracted? |
| 2024-11-05 21:38:57 +0100 | Guest5 | (~Guest5@137.79.192.219) (Client Quit) |
| 2024-11-05 21:38:33 +0100 | <monochrom> | That is strange. I thought it was 2024 and no one would set up x.y.com without also setting up y.com. |
| 2024-11-05 21:37:53 +0100 | Guest5 | (~Guest5@137.79.192.219) |
| 2024-11-05 21:37:30 +0100 | Guest7 | (~Guest7@137.79.192.219) |
| 2024-11-05 21:37:26 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 265 seconds) |
| 2024-11-05 21:37:19 +0100 | <monochrom> | OK right it has to be subscriptions.techstreet.com |
| 2024-11-05 21:36:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-05 21:36:21 +0100 | <tomsmeding> | that doesn't seem to have an A record |
| 2024-11-05 21:36:02 +0100 | <monochrom> | or rather, links me to. |
| 2024-11-05 21:35:56 +0100 | <tomsmeding> | O.o |
| 2024-11-05 21:35:51 +0100 | <monochrom> | My university library website refers me to techstreet.com. |
| 2024-11-05 21:35:40 +0100 | <tomsmeding> | that's funny |
| 2024-11-05 21:35:20 +0100 | <monochrom> | So basically they left, e.g., _ _STDC_VERSION_ _ defined as 201ymmL and forgot to fix that. The corrigendum then said "oh we mean 201112L". There are a couple others similar macros. |
| 2024-11-05 21:34:09 +0100 | SlackCoder | (~SlackCode@64-94-63-8.ip.weststar.net.ky) (Quit: Leaving) |
| 2024-11-05 21:34:09 +0100 | <tomsmeding> | monochrom: from where did you download that? I wanna check if my university pays for this madness too |
| 2024-11-05 21:33:53 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2024-11-05 21:33:23 +0100 | monochrom | downloaded the finalized C11 through university access, and snickers at the uncaught typo they had to publish a corrigendum later. |
| 2024-11-05 21:29:22 +0100 | son0p | (~ff@181.237.206.243) son0p |
| 2024-11-05 21:27:55 +0100 | <tomsmeding> | monochrom: reflecting a little bit, while 6.2.6.1#4 is overly restrictive in only allowing to copy _to_ unsigned char[n] and not necessarily _from_, footnote 99 in 6.5.2.3#3 does say that as long as you don't hit trap representations, you can convert through a union |
| 2024-11-05 21:25:50 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-11-05 21:25:17 +0100 | briandaed | (~root@185.234.210.211) (Remote host closed the connection) |
| 2024-11-05 21:20:55 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-05 21:20:00 +0100 | <tomsmeding> | otherwise, in 6.2.6.2#5, the "(non-trap)" would be redundant |
| 2024-11-05 21:19:24 +0100 | <tomsmeding> | probie: in my reading of the standard, it doesn't guarantee that `int` has no trap representations |
| 2024-11-05 21:15:01 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-11-05 21:14:56 +0100 | <probie> | I just mean that you're guaranteed a representation. The core standard itself defines that for ints, but if `__STDC_IEC_559__` isn't defined, there's nothing stopping an implementation having `float` and `double` be the same type, or using something different to what you'd expect, like posits |
| 2024-11-05 21:11:28 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2024-11-05 21:11:14 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2024-11-05 21:06:39 +0100 | <tomsmeding> | is there a similar thing for `int`? |
| 2024-11-05 21:06:31 +0100 | <tomsmeding> | probie: is that guaranteed to have no trap representations? |
| 2024-11-05 21:06:11 +0100 | <probie> | If you want to "be safe" you also probably need to check that `__STDC_IEC_559__` is defined, so that you're guaranteed the normal IEEE-754 representations for floats |
| 2024-11-05 21:04:54 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) justsomeguy |
| 2024-11-05 21:03:09 +0100 | euphores | (~SASL_euph@user/euphores) (Ping timeout: 246 seconds) |
| 2024-11-05 21:03:04 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) (Ping timeout: 272 seconds) |
| 2024-11-05 21:02:43 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |