2024/11/05

Newest at the top

2024-11-05 22:11:54 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-11-05 22:07:21 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2024-11-05 22:05:29 +0100CoolMa7(~CoolMa7@ip5f5b8957.dynamic.kabel-deutschland.de) CoolMa7
2024-11-05 21:59:21 +0100Guest7(~Guest7@137.79.192.219)
2024-11-05 21:59:02 +0100Guest7(~Guest7@137.79.192.219) (Remote host closed the connection)
2024-11-05 21:56:38 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-11-05 21:51:59 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2024-11-05 21:44:42 +0100sprotte24(~sprotte24@134.245.44.86) (Ping timeout: 276 seconds)
2024-11-05 21:41:27 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds)
2024-11-05 21:40:37 +0100sprotte24_(~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 +0100Guest5(~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 +0100Guest5(~Guest5@137.79.192.219)
2024-11-05 21:37:30 +0100Guest7(~Guest7@137.79.192.219)
2024-11-05 21:37:26 +0100lxsameer(~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 +0100merijn(~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 +0100SlackCoder(~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 +0100machinedgod(~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod
2024-11-05 21:33:23 +0100monochromdownloaded 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 +0100son0p(~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 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2024-11-05 21:25:17 +0100briandaed(~root@185.234.210.211) (Remote host closed the connection)
2024-11-05 21:20:55 +0100merijn(~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 +0100weary-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 +0100euphores(~SASL_euph@user/euphores) euphores
2024-11-05 21:11:14 +0100L29Ah(~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 +0100justsomeguy(~justsomeg@user/justsomeguy) justsomeguy
2024-11-05 21:03:09 +0100euphores(~SASL_euph@user/euphores) (Ping timeout: 246 seconds)
2024-11-05 21:03:04 +0100ljdarj1(~Thunderbi@user/ljdarj) (Ping timeout: 272 seconds)