00:35:01 -!- Noisytoot has quit (Excess Flood).
00:36:10 -!- Noisytoot has joined.
00:40:07 -!- Noisytoot has quit (Excess Flood).
00:40:40 -!- Noisytoot has joined.
01:18:58 -!- ais523 has quit (Quit: quit).
03:00:00 -!- Taneb has quit (Quit: I seem to have stopped.).
03:01:12 -!- Taneb has joined.
03:18:35 -!- Noisytoot has quit (Ping timeout: 264 seconds).
03:49:45 -!- Noisytoot has joined.
03:52:51 -!- Noisytoot has quit (Client Quit).
03:58:07 -!- Noisytoot has joined.
04:29:15 <esolangs> [[Brainfuck]] https://esolangs.org/w/index.php?diff=125964&oldid=125946 * EvyLah * (+101) ><> implementation
04:34:16 -!- Noisytoot has quit (Ping timeout: 268 seconds).
04:38:58 <esolangs> [[Hi]] https://esolangs.org/w/index.php?diff=125965&oldid=119779 * EvyLah * (+202) ><> + brainfuck implementation
04:43:59 <esolangs> [[7 bytes XD]] https://esolangs.org/w/index.php?diff=125966&oldid=113716 * EvyLah * (+80)
06:00:02 -!- Sgeo has quit (Read error: Connection reset by peer).
06:29:11 <visilii> Every time I think I got an original idea for an esolang, I find it already implemented and posted on esolang wiki in two different variants. I guess I should stop lurking the wiki and start actually doing something, eh
06:29:29 <visilii> I'm kinda new to the whole esoteric language thing and the amount of different esolangs is astounding to me!
06:43:15 -!- tromp has joined.
06:47:14 <esolangs> [[Special:Log/newusers]] create * Xyper * New user account
07:08:34 <esolangs> [[Special:Log/newusers]] create * RemTwo * New user account
07:10:11 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
07:13:05 -!- tromp has joined.
08:07:57 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
08:44:13 <b_jonas> visilii: I haven't experienced that, but I've been sitting on Consumer Society for years now, and it's such a natural and reinventable idea that I constantly have a low-level fear that either someone will create it before I write it down, or else it's been invented years ago and I just never found it on the internet
08:45:58 <int-e> witness the power of procrastination
08:47:00 <b_jonas> the central conceit that is; I don't mind if the other three twists that I thought about for are taken:
08:48:11 <b_jonas> (1) one twist is that I'll define two variants, one where one kind of parenthesis needs to be balanced for the program to be syntactically valid, another where it's another kind of parenthesis, so when I take the union of those two languages as one language that autodetects which language you're speaking when you run a program, the union language is context-free but not deterministically context-free
08:49:36 <b_jonas> (2) the second twist is that debug string literals work like they usually use > as the starting delimiter and < as the ending delimiter, but you can also use < as the starting delimiter in which case that delimiter is included in the string, which is an easy way to make it so you don't need escapes in those literals, and
08:52:13 <b_jonas> (3) this one I think I haven't mentioned yet, but I want to take revenge on ais523 for inventing the mind bug that is the attract and repel arithmetic operations in Nellephant, by defining an arithmetic standard library that has attract and repel but also sane arithmetic operations like add and compare and bitwise or, but I'll define it so that most of the sane operations are documented as being
08:52:19 <b_jonas> undefined behavior if ais523 is writing the program that invokes them, so he's forced to either use attract and repel, or write programs that although work perfectly in every foreseeable implementations they technically invoke undefined behavior
09:03:09 <b_jonas> I'm using angle brackets for debug string literals mostly to ride on the confusion how french texts usually use guillamots pointing outside for a quote like « foo », while german texts use guillamots pointing inside like »foo«
09:06:18 <b_jonas> somehow I never see people put obviously unenforcable ridiculous conditions into their language definitions under the threat of undefined behavior, they instead try to put those obviously unenforcable conditions to some kind of license under the threat of license termination.
09:08:08 <int-e> Hmm C is trying so hard though
09:13:48 <int-e> The other day I was looking at https://tweetnacl.cr.yp.to/20140427/tweetnacl.c and now I'm wondering whether `car25519` really avoids shifting negative numbers. I guess I could instrument the code to figure that out.
09:18:46 -!- tromp has joined.
09:35:44 <int-e> It does not. It also fails to verify a signature even though libsodium does like it... but that may still be my fault.
09:38:21 <b_jonas> int-e: ok, but that's more not cleaning up an existing undefined behavior rule in a timely manner, because when C started there really were machines that represented integers as ones' complement or sign-magnitude, so not shifting negative numbers was a simple rule the C standard could specify. most code that wants to shift negative numbers probably already assume two's complement repr, and if you
09:38:27 <b_jonas> compile them on a two's complement machine then you can look at the manual for the compiler for what that promises about shifting signed numbers, and look, indeed https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Integers-implementation.html tells you how shifts work, it's just the "boo hoo your code isn't unconditionally compliant with the C standard, it calls a platform-dependent function for like
09:38:33 <b_jonas> displaying colored graphics so it's not real C" crowd that keep enforcing the signed shift undefined thing
09:42:19 <b_jonas> and even that would be fine if they, like, added a standar library function/macro that does two's complement numbers and is a compile time error on machines that aren't two's compliment, and to be fair they started to do that with at least some floating-point stuff, but not for shifts yet as far as I can tell, so they'll just lose more people to zig and rust which do have built-in functions for simple
09:42:25 <b_jonas> operations like shifting a number that your CPU can already do anyway
09:42:31 <fizzie> C23 nails down the integer representation as two's complement, but keeps right-shifting a negative number implementation-defined (and left-shifting one undefined), so clearly it's not just a representation thing in the minds of the standardization committee.
09:44:03 <b_jonas> they could even keep the convenient infix notation if they defined type aliases similar to int32_t that only exist if it's two's complement and signed shifts work on two's complement overflowing
09:45:07 <b_jonas> fizzie: it's not just a representation thing, it's a "don't silently break new programs on weird old compilers" thing, which is reasonably, but there are library solutions for that
09:45:59 <b_jonas> like, I actually don't like some of the C++ core rules changes about evaluation order that can break new programs on old compilers silently
09:46:18 <b_jonas> but if you make a clean interface where the program will fail to compile on those compilers then it's fine
09:46:56 <int-e> b_jonas: the irony here is that there *is* an attempt to avoid undefined or implementation-defined behavior, namely that initial addition of 1<<16. So the invariant is that all values are at least -1 << 16. But that requires carry propagation in Z() (subtraction) and that's missing.
09:50:51 -!- user3456 has quit (Quit: I use ZNC - https://znc.in).
09:51:05 <b_jonas> as for weird numeric unspecified behavior for portability, I should stop procrastinating and figure out how to report that bug in qemu where the unoptimized implementation for x86 SSE instructions can give the wrong NaN results on two NaN inputs, because the implementation that comes from softfp tries to use the x87 NaN rules instead of the SSE NaN rules. it's just that reporting this is tricky because
09:51:11 <b_jonas> they'll probably laugh me off unless I make a full repro.
09:52:02 <b_jonas> this is one that likely never causes symptoms because who the heck takes a program optimized to use the NaN rules of the specific hardware, then runs it in an unoptimized emulator that doesn't take advantage of said hardware, rather than the optimized version that uses SSE instructions to emulate SSE instructions
09:54:20 <b_jonas> wait, I didn't say the fun part
09:55:50 <b_jonas> this only comes up if you call the SSE instruction from assembly code or inline assembly, because if you use the operators of C or even the SSE intrinsics then even with the strictest settings the compiler has the right to "optimize" floating-point operations in ways that change which NaN value you get as the result, such as swapping the operands of an addition, so if you don't use assembly then a
09:55:56 <b_jonas> future gcc optimization could just break your repro (though it's not very likely that it'll do that if you use division, whose operands are hard to swap)
10:10:02 -!- user3456 has joined.
10:16:27 -!- user3456 has quit (Ping timeout: 252 seconds).
10:18:36 -!- user3456 has joined.
10:29:56 <int-e> (The failure to verify a signature that is; the shifting negative numbers right thing is real.)
10:34:48 -!- Lord_of_Life_ has joined.
10:35:30 -!- Lord_of_Life has quit (Ping timeout: 256 seconds).
10:36:09 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
10:43:49 -!- Noisytoot has joined.
10:48:27 -!- wib_jonas has joined.
10:49:51 <wib_jonas> also to describe the correct behavior of the instructions with two NaN inputs, you have to talk about which operand of the SSE instructions is first vs second input operand, which gets complicated by Intel vs AT&T assembly syntax.
10:50:36 <wib_jonas> and then you have to deal with three-input FMA instructions, newer instructions that have two input and a separate output operand, and more.
10:53:39 <wib_jonas> int-e: wait, is that the size-reduced cryptography source code thing?
10:54:16 <wib_jonas> I didn't realize that because it has "tweet" instead of "t-shirt" or "tattoo" in its name
10:55:18 <int-e> it's "tweet" because they tweeted it out as a series of tweets
11:12:10 <wib_jonas> int-e: only before I looked at the source code, I saw a url that has "tweet" in its domain name, which sounded like either another twitter mirror website that tries to let you read twitter without going through their interface, or an attempt for a twitter alternative, and then I assumed it'd have yet another "C language is crazy, why is this simple
11:12:11 <wib_jonas> thing UB" message on that. that, or maybe a crypto protocol tunneled through twitter.
11:15:55 <esolangs> [[User talk:None1]] M https://esolangs.org/w/index.php?diff=125967&oldid=125880 * None1 * (+196)
11:23:33 <esolangs> [[Fairytale]] https://esolangs.org/w/index.php?diff=125968&oldid=125958 * Leomok2009 * (+14) Fixed mistake in translated code
11:24:13 <esolangs> [[Fairytale]] https://esolangs.org/w/index.php?diff=125969&oldid=125968 * Leomok2009 * (+8)
11:25:15 -!- amby has joined.
12:21:42 -!- ais523 has joined.
12:26:44 <esolangs> [[Anti-Machine language]] https://esolangs.org/w/index.php?diff=125970&oldid=125842 * Cleverxia * (+223) /* Implementations (?) */
12:51:45 -!- ais523 has quit (Remote host closed the connection).
12:52:58 -!- ais523 has joined.
13:03:02 -!- ais523 has quit (Remote host closed the connection).
13:04:15 -!- ais523 has joined.
13:10:33 <esolangs> [[Do while true]] N https://esolangs.org/w/index.php?oldid=125971 * Cleverxia * (+1492) Created page with "Do while true is an esolang, where every line is an expression. ==Syntax== There is a stack. Every line is an expression in postfix notation (1 2- equals -1) and evaluated from left to right (72o105o-No prints Hi! and equals -33). The intepreter first does tha
13:35:24 -!- ais523 has quit (Ping timeout: 268 seconds).
13:46:01 -!- ais523 has joined.
14:24:03 <esolangs> [[JustWords]] https://esolangs.org/w/index.php?diff=125972&oldid=123728 * Kaveh Yousefi * (+473) Supplemented an alternative truth-machine implementation, as well as two further example programs.
14:25:31 <esolangs> [[JustWords]] https://esolangs.org/w/index.php?diff=125973&oldid=125972 * Kaveh Yousefi * (+249) Added a hyperlink to my implementation of the JustWords programming language on GitHub and supplemented two page categories.
14:42:12 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
15:10:49 -!- tromp has joined.
15:16:52 -!- perlbot has quit (Quit: ZNC 1.8.2+deb3.1 - https://znc.in).
15:16:52 -!- simcop2387 has quit (Quit: ZNC 1.8.2+deb3.1 - https://znc.in).
15:21:08 -!- __monty__ has joined.
15:35:52 -!- simcop2387 has joined.
15:37:50 -!- perlbot has joined.
16:28:23 -!- simcop2387 has quit (Read error: Connection reset by peer).
16:28:23 -!- perlbot has quit (Read error: Connection reset by peer).
16:33:26 -!- wib_jonas has quit (Quit: Client closed).
16:34:22 -!- perlbot has joined.
16:34:55 -!- simcop2387 has joined.
16:40:19 -!- integral_ has joined.
16:42:23 -!- integral has quit (Ping timeout: 268 seconds).
16:42:24 -!- b_jonas has quit (Ping timeout: 268 seconds).
16:42:26 -!- Hooloovoo has quit (Ping timeout: 268 seconds).
16:42:27 -!- integral_ has changed nick to integral.
16:42:49 -!- b_jonas has joined.
16:43:14 -!- Hooloovoo has joined.
16:50:56 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
16:51:35 -!- simcop2387 has quit (Read error: Connection reset by peer).
16:51:35 -!- perlbot has quit (Read error: Connection reset by peer).
16:56:34 -!- perlbot has joined.
16:57:02 -!- simcop2387 has joined.
17:00:45 <ais523> b_jonas: surely the workaround is for me to create a compiler so that it's writing the program, not me, and now there's no UB
17:02:16 <ais523> I think I had a good reason for attract/repel although I can't remember what it was (probably related to Nellephant not being TC, meaning that you can't simulate more complex operations using simpler ones the same way as in a TC language, so I had to go with primitives that were powerful enough to actually do everything the langauge needed to do)
17:02:32 <ais523> like, probably my first thought was increment/decrement and then I wasn't sure that would work
17:03:06 <ais523> as for the two's complement argument, I don't understand why shifts weren't just defined arithmetically
17:04:06 <ais523> e.g. you could define x << y as (x * 2**y), with UB if y is negative or if the result overflows (signed case), or wrapping on overflow (unsigned case)
17:04:33 * ais523 wonders whether, if multiplication is * and exponentiation is **, tetration should be ***
17:05:16 <ais523> as for right-shifting negative numbers, most hardware has two different right-shift operators to handle the two possible meanings of a right-shift, and it is strange that C doesn't provide access to both of htem
17:05:22 <int-e> ais523: but 1-s complement!!!1eleven
17:05:42 <ais523> 1's complement can implement that
17:05:45 <fizzie> That "arithmetic" definition is how it *is* defined.
17:05:52 <fizzie> C11 6.5.7p4: "The result of E1 << E2 ... If E1 has an unsigned type, the value of the result is E1 * 2**E2, reduced modulo one more than the maximum value representable in the result type. If E1 has a signed type and nonnegative value, and E1 * 2**E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined."
17:05:55 <ais523> it doesn't correspond to a single machine instruction, but it can implement it
17:06:16 <int-e> but then the 1s complement left shift is different for unsigned and signed
17:06:20 <ais523> fizzie: ah, that makes the 1's complement versus 2's complement even weirder
17:07:00 <fizzie> And for E1 >> E2: "If E1 has an unsigned type or if E1 has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1 / 2**E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined."
17:07:08 <ais523> fizzie: oh, no, haha, "reduced modulo one more than the maximum value representable in the result type"
17:07:19 <ais523> so it provides different answers in 1's complement and 2's complement systems
17:07:19 -!- tromp has joined.
17:07:23 <ais523> but then, I guess so does addition
17:07:37 <fizzie> That's for unsigned types only.
17:07:44 <ais523> all-bits-1 is a valid nonzero unsigned number even in 1's complement systems, isn't it
17:07:57 <ais523> no wonder people stopped using them, they don't handle unsigned numbers at all well
17:09:29 <ais523> so the maximum value representable is there to handle padding bits, I guess (which for all I know are also banned for unsigned numbers)
17:09:55 <ais523> fwiw, I realised a while back that it would be a huge simplification/optimisation for processors to simply store an extra couple of bits in their registers, compared to the in-memory representation
17:10:11 <ais523> e.g. you have 66-bit registers in your otherwise 64-bit processor
17:10:39 <int-e> is this for carries and overflows?
17:10:40 <ais523> and the memory read operations specify bitwidth and sign-/zero-extension, the memory write operations specify bitwidth and signed saturation / unsigned saturation / wrapping
17:10:51 <ais523> it's to entirely replace all uses of flags
17:11:05 <ais523> instead of branching on a flag, you branch on the high bits of a register
17:11:16 <ais523> and this means that the processor doesn't have a global variable it needs to track any more
17:11:24 <int-e> "all uses of flags" hmm, I wonder whether anybody ever uses Intel's parity flag.
17:11:35 <fizzie> Padding bits are still allowed for unsigned types. And I think you could have a conforming implementation where (for example) signed integers are sign-and-magnitude, and unsigned types just treat the sign bit as a padding bit; so INT_MAX == UINT_MAX.
17:11:37 <ais523> well, you can just look at the low bits for that one
17:11:49 <ais523> although, the x86 parity flag isn't very useful because it just takes the parity of the bottom 8 bits of the result
17:12:23 <fizzie> C11 6.2.6.2p2: "For signed integer types -- Each bit that is a value bit shall have the same value as the same bit in the object representation of the corresponding unsigned type (if there are M value bits in the signed type and N in the unsigned type, then M ≤ N)."
17:12:32 <ais523> which means that doing a popcount and taking the bottom bit is normally more efficient than using the parity flag, because you can check the parity of more bits at once
17:12:54 <fizzie> Which allows the M = N case, where the signed type has the same value bits as the corresponding unsigned type.
17:13:11 <ais523> in 1's and 2's complement, is the most significant bit considered a sign bit rather than a value bit? or both a sign bit and a value bit?
17:13:25 <ais523> I guess it's probably "rather than"
17:13:26 <fizzie> It's considered a sign bit.
17:14:02 <fizzie> ("-- the bits of the object representation [of a signed integer type] shall be divided in into three groups: value bits, padding bits, and the sign bit. -- There shall be exactly one sign bit.")
17:14:45 <ais523> I guess the sign bit isn't required to be at the top
17:14:57 <ais523> C probably doesn't care about bit order at all, it's hard to observe
17:15:07 <ais523> (byte order is observable in C, though)
17:15:14 <fizzie> "If the sign bit is one, the value shall be modified in one of the following ways: - the corresponding value with sign bit 0 is negated (/sign and magnitude/); - the sign bit has the value -(2**M) (/two's complement/); - the sign bit has the value -(2**M-1) (/ones' complement/)."
17:16:13 <ais523> fwiw, I vaguely remember sign-magnitude being invented first, then one's complement, then two's complement
17:16:52 <ais523> which could be the reason why the other systems persisted – two's complement is obviously the best of those systems from the point of view of a) implementation simplicity and b) avoiding special cases that can trip up programmers
17:17:18 <ais523> (the main issue is with INT_MIN, which isn't symmetrical to INT_MAX)
17:17:27 <fizzie> Incidentally, pre-C23 the "value with sign bit 1 and all value bits zero" is allowed to be a trap representation even if the integer representation was two's complement.
17:17:35 <fizzie> If it is, then the range is of course symmetrical.
17:17:37 <ais523> or the infamous INT_MIN/-1 overflow which is the only case where a division by a number other than 0 can overflow
17:17:50 <int-e> One's complement is just weird to me. sign-magnitude makes a lot of sense and is familiar from floating point and various multiple precision arithemetic implementations.
17:18:06 <int-e> Hmm s/various/a number of/ would've been punnier.
17:18:08 <ais523> fizzie: there are definitely some advantages to 1000…000 trap representation, but also some disadvantages, and I think it never really caught on
17:18:20 <ais523> it's a trap representation for floats too, isn't it? or at least some sort of NaN?
17:19:27 <int-e> "is just weird to me" - what is this representation actually good at?
17:20:18 <ais523> which is not a trap representation or even a particularly badly-behaving number, although it's weird
17:20:43 <ais523> int-e: it's better than sign-magnitude, it has most but not all the advantages of two's complement
17:20:47 <ais523> and I think it was invented first
17:23:01 <int-e> I guess there are tricks like feeding in the sign bit as a carry for addition that make one-s complement tolerable.
17:23:11 <fizzie> Negative zero is allowed for (non-two's-complement) integers as well, but there's some restrictions on what can produce one (in particular, the more "arithmetic" operators +-*/% cannot produce a negative zero unless one of the operands is a negative zero to begin with), and a negative zero may silently decay into a regular zero when stored in an object.
17:23:49 <ais523> int-e: here's what I was thinking of: https://en.wikipedia.org/wiki/Pascal%27s_calculator#9's_complement
17:24:07 <ais523> was invented in 1642, I think that easily beats 2's complement :-)
17:24:20 <int-e> and I guess xor-with-sign is a good way to prepare for full precision multiplication
17:24:29 <ais523> fizzie: this means that -0 is actually the additive identity
17:24:36 <ais523> because it'll decay when added to 0, but not to another -0
17:25:44 <int-e> So okay, maybe overall that makes it slightly better than sign-magnitude.
17:26:29 <fizzie> My grandmother's place had one of those mechanical calculators that looked like this: https://www.researchgate.net/publication/322506360/figure/fig1/AS:613889318338573@1523374027460/The-mechanical-calculator-Walther-source-Walther-Calculators.png
17:26:35 <fizzie> Not working particularly well, alas.
17:26:47 <fizzie> Still fun to play with.
17:26:55 <ais523> (also, Pascal's calculator had a good reason to use 9's rather than 10's complement – it made the "negate" operation easy to do mechanically or even optically)
17:28:12 <int-e> oh color coding on the wheels? neat
17:43:01 -!- ais523 has quit (Quit: playing a bridge tournament).
18:18:18 <b_jonas> ais523: I think the reason why C doesn't specify how signed shift on negative arguments works on machines that aren't two's complement is that some such machines will likely have just unsigned shift instructions, and that instruction doesn't work correctly as a signed arithmetic shift, that is, it doesn't just multiply by a power of two then do a one's complement reduction. shifting positive signed
18:18:25 <b_jonas> numbers is still useful, and the one shift instruction still works for that. and I think people stopped using representations other than two's complement is that two's complement makes multi-word integer arithmetic easier.
18:21:11 <b_jonas> "store an extra couple of bits in their registers" => https://esolangs.org/wiki/Apollo_Guidance_Computer does store an extra bit for its registers, though this happens in a somewhat unfortunate way where that extra bit is used as *input* to arithmetic on those registers too, not just output, which makes the rules rather ugly. 6502 just has a carry bit that works basically the same as if you had an extra
18:21:17 <b_jonas> bit for the accumulator, in particular the carry bit is 1 when there's no unsigned overflow on a *subtraction*, unlike on x86.
18:23:04 <b_jonas> ais523: and note that the AGC has 16 bits in registers, 15 bits in memory words, but for multiword arithmetic the high word is worth 2**14 times the lower word, because the normal 2**15 would be hard on a ones' complement machine, and note that the AGC has double-precision arithmetic instructions in hardware (triple-precision in software only).
18:23:54 <b_jonas> also x86_64 now has 64-bit GP registers but 32-bit memory operands by default, but I know that's not what you were thinking of.
18:24:29 <b_jonas> int-e: parity flag => I think back in the early PC days people used it for serial port communication.
18:25:29 <b_jonas> "Padding bits are still allowed for unsigned types." => IIUC only for bigger unsigned integer types, but not allowed for unsigned char, so I don't think that allowance is useful for anything in practice
18:26:11 <b_jonas> "you could have a conforming implementation where (for example) signed integers are sign-and-magnitude, and unsigned types just treat the sign bit as a padding bit" => no, I think the C standard says things about signed vs unsigned integer types that forbid that
18:29:06 <b_jonas> "sign-magnitude being invented first ... which could be the reason why the other systems persisted" => no, I think it's because the earliest computers were optimized more for numeric calculation with large numbers, and if you want to build a computer that does division and square root in hardware then sign-magnitude suddenly isn't that bad
18:29:29 <b_jonas> like think of the Babbage thing
18:30:43 <b_jonas> "it's a trap representation for floats too, isn't it? or at least some sort of NaN?" => no, it's just minus zero. all one bits is one of the minus NaNs.
18:32:24 <b_jonas> "which is not a trap representation or even a particularly badly-behaving number, although it's weird" => negative zero is the additive unit of floating point numbers. it shouldn't be, but the x87 designers who specified IEEE floats messed up and defined addition in a way where 0+(-0) is a positive zero, so now we're stuck with negative zero being the true zero, and it's too late to change that.
18:33:49 <b_jonas> "this means that -0 is actually the additive identity" => wait, there were computers that did that for integers too? now that's messed up.
18:33:49 <int-e> oh the apollo thing
18:34:38 <b_jonas> the mechanical calculators that I've seen are ten's complement, not nines' complement. even some early digital calculators are.
18:34:56 <fizzie> The one thing the standard says in the "representations of integer types" section about the corresponding signed/unsigned pairs is what I already quoted, and seems to allow the case where the unsigned type just includes the nonnegative half of the signed type.
18:34:59 <fizzie> Namely, this one: "Each bit [of the object representation of a signed integer type] that is a value bit shall have the same value as the same bit in the object representation of the corresponding unsigned type (if there are M value bits in the signed type and N in the unsigned type, then M ≤ N)."
18:35:00 <b_jonas> int-e: https://esolangs.org/wiki/Apollo_Guidance_Computer
18:35:02 <fizzie> If M = N (which is allowed by M ≤ N), the signed integer type's nonnegative values is the same set as the unsigned integer type's entire range of values.
18:35:30 <int-e> b_jonas: Yeah I looked it up recently actually, just didn't recall immediately.
18:35:41 <int-e> (You mentioned it before.)
18:35:46 <b_jonas> fizzie: which standard are you looking at, just to be clear? C99?
18:36:25 <fizzie> C11 (the N1570 draft), which is for some reason the one I've settled on as a default.
18:36:45 <b_jonas> that's fine, I just didn't want to have to compare multiple standards for this
18:36:47 <int-e> mostly the C standard has to ensure that copying bytes of in-memory objects preserves their values
18:37:37 <b_jonas> totality in the solar eclipse is now mostly in the US
18:37:38 <int-e> if bytes had padding then that would become awkward
18:38:26 <int-e> the sun is totally eclipsed by the Earth here
18:39:48 <fizzie> For C23, I'm using the N3096 draft. That one only allows the "normal" two's complement situation. N3096 6.2.6.2p2: "If the corresponding unsigned type has width N, the signed type uses the same number of N bits, its /width/, as value bits and sign bit. N - 1 are value bits and the remaining bit is the sign bit."
18:40:29 <fizzie> There's no eclipse in London either, but apparently in the very westernmost bits of the UK (and Ireland certainly) you could have had a partial eclipse near sunset.
18:40:35 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
18:40:44 <fizzie> Except at least here it's rainy and very overcast.
18:41:30 <b_jonas> yes, Scotland will have a rather unimpressive partial eclipse
18:42:49 <int-e> hmm... we're past equinox so being further north helps too?
18:43:20 <int-e> not sure how significant that is
18:43:24 <fizzie> Yes. Though UK also leans west, so going "north" helps with that too.
18:43:48 <int-e> (it's only been 3 weeks)
18:45:53 <fizzie> We went to Isle of Skye once. Looking up a map, they'll have a 22.4% of an eclipse.
18:46:03 <fizzie> Well, I guess any amount counts as "an eclipse", but still.
18:46:48 -!- tromp has joined.
18:49:43 <zzo38> Is recv with the MSG_PEEK flag sufficient to check if the client is using TLS to connect to the server (by checking whether or not the first byte is 0x16) so that the server can use TLS and non-TLS depending on the client?
18:51:09 <b_jonas> "<ais523> ... create a compiler [to Consumer Society]" => yes, and if that's easy if I was wrong and it's actually easy to impelment ordinary arithmetic based on attract and repel, and this is by design
18:52:25 <b_jonas> "<ais523> first thought was increment/decrement" => right, but even if increment/decrememtn doesn' towrk, wouldn't your next thought be something like subtraction and less-than comparison, or subtraction that fails on a borrow?
18:53:35 <b_jonas> zzo38: that must depend on the other protocol that you want to distinguish from TLS
18:54:24 <b_jonas> but IIRC in TLS the first byte is a low byte (between 0 and 16) while in HTTP it's an ascii letter, so it should indeed be that simple
18:55:12 <b_jonas> though check your TLS library first, maybe it already has something built-in for this, letting you read non-TLS when the client speaks non-TLS
18:55:50 <b_jonas> I don't know how this works for DNS for example
19:03:28 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
19:03:49 <zzo38> b_jonas: Yes, I know that it depends what other protocol. I wrote the Scorpion protocol specification and the first byte is always a uppercase ASCII letter, so it can always be distinguished from TLS in this way. As far as I know, OpenSSL has no such thing and I don't know if any other one does (I have not looked at them).
19:04:10 <zzo38> I don't know its working with DNS either. But, if it cannot be distinguished in this way, then you can use separate port number for TLS and non-TLS.
19:04:37 -!- tromp has joined.
19:22:01 <b_jonas> I know HTTP and IRC have separate port numbers for TLS versus don-TLS, but I don't know why
19:27:08 <int-e> there's the whole starttls mess too
19:35:03 <zzo38> I think it is simpler to do the way I had done it, though. Someone complained that it is difficult to detect TLS vs non-TLS in this way, although it does not seem so difficult to me. However, I have not actually tried it, so I may be wrong.
19:35:43 <zzo38> Also, I think I have once tried to connect to a HTTPS server without TLS, and it did respond with a proper HTTP response containing an error message (that says that non-TLS is not allowed).
19:37:06 <Noisytoot> IRC has STARTTLS: https://ircv3.net/specs/deprecated/tls.html, it's just that nothing supports it and it's deprecated
19:40:02 <b_jonas> should I have chosen an eclipse-related password of the month? or would that have been boring?
19:40:19 <int-e> There's an old internet draft for telnet too: https://datatracker.ietf.org/doc/html/draft-ietf-tn3270e-telnet-tls-02
19:40:22 <b_jonas> also http://sigbovik.org/2024/ still says "The proceedings are not yet available as the conference has not yet proceeded." even though the conference has proceeded already.
19:40:48 <int-e> b_jonas: Yeah is the program available anywhere?
19:44:19 <b_jonas> int-e: I don't know, but there were very few live presentations. the video should still be available on twitch.tv
19:44:32 <b_jonas> there'll be much more articles in the proceedings than presentations
19:44:45 <int-e> But I don't want to go through a video.
19:45:15 <b_jonas> int-e: should I summarize tom7's presentation?
19:47:15 <int-e> Not really... I'm more interested in a list of contributions. I'll wait.
20:14:13 <int-e> This will do the trick for now: https://github.com/sigbovik/sigbovik/blob/20e0e2d7cddf2357d8a288a9116461c2d2621ee6/papers.tex
20:14:40 <int-e> (the papers are in the repo too, but I really wanted a table of contents)
20:22:14 <b_jonas> oh no! so the C and C++ standards use the phrase "unsigned integer types" differently: bool is a C "unsigned integer type" but not a C++ "unsigned integer type". that kind of thing can be confusing when C++ includes a large part of the C standard library by reference: if the definition of the library mentions an "unsigned integer type", what does it mean? in particular, is the library allowed to define
20:22:20 <b_jonas> the type alias uint1_t for bool?
20:26:18 <int-e> b_jonas: the C++ thing makes more sense though seeing how true + true becomes true when casted back to a bool.
20:26:46 <int-e> rather than doing arithmetic modulo 2.
20:28:58 <b_jonas> I'm still trying to understand what the standard says, but you may be right in that the sized integer type could have either the same number of bits as the unsigned type or one more bit
20:31:07 <b_jonas> yeah, it seems like the text does want to allow that
20:31:45 <b_jonas> that probably actually makes sense for a sign-magnitude computer
20:31:56 <b_jonas> I didn't know this, thank you
20:53:49 <b_jonas> so, I already knew that if you add a signed long long to an unsigned long, then on x86_64-linux where both those types are 64 bits long, the result is an unsigned long long; on x86_64-windows where unsigned long is 32 bit wide, the result is a signed long long. but now it turns out that if you add a signed long to an unsigned long long, although normally the result is an unsigned long long, on a
20:53:55 <b_jonas> hypothetical computer with weird integer types the result could be a signed long.
20:54:49 <b_jonas> but I might be getting that wrong, don't trust me on taht
20:55:35 -!- ais523 has joined.
20:58:14 -!- ais523 has quit (Read error: Connection reset by peer).
20:58:40 -!- ais523 has joined.
21:05:35 <fizzie> That's also a difference between x86-32 Linux and x86-64 Linux, because of the same difference in type sizes, though I guess it's less surprising since it's, after all, a 32-bit vs. 64-bit thing. As observed in practice: https://0x0.st/Xige.txt
21:17:41 -!- ais523 has quit (Remote host closed the connection).
21:18:06 -!- ais523 has joined.
21:23:16 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
21:27:12 <b_jonas> that reminds me of a question. gcc supports 128-bit integer types (signed and unsigned) __int128, but it defines intmax_t as 64 bytes wide, because defining it as 128-bit wide would break binary compatibility with previous implementations where it was 64-bit wide. The C standard says that intmax_t is the widest integer type. Should I consider the gcc __int128 type not a "signed integer type" for the C
21:27:18 <b_jonas> standard purposes? Or would that have too many weird consequences mandated by the C standard, and so instead I should consider __int128 a signed integer type and say that gcc sensibly breaks the rule about intmax_t being the widest? Same question about the C++ standard.
21:29:48 <ais523> b_jonas: I read a good blog post about this recently
21:30:01 <ais523> here we go: https://thephd.dev/intmax_t-hell-c++-c
21:30:32 <esolangs> [[Compaline]] https://esolangs.org/w/index.php?diff=125974&oldid=118090 * Ice Bird * (+3219)
21:31:16 <esolangs> [[Compaline]] https://esolangs.org/w/index.php?diff=125975&oldid=125974 * Ice Bird * (+39)
21:33:29 <esolangs> [[Compaline]] https://esolangs.org/w/index.php?diff=125976&oldid=125975 * Ice Bird * (-27)
21:33:45 <esolangs> [[Compaline]] https://esolangs.org/w/index.php?diff=125977&oldid=125976 * Ice Bird * (+2)
21:35:29 <esolangs> [[Compaline]] https://esolangs.org/w/index.php?diff=125978&oldid=125977 * Ice Bird * (+6)
21:38:44 -!- __monty__ has quit (Quit: leaving).
21:43:01 <fizzie> C23 explicitly allows both the new /bit-precise integer types/ (`_BitInt(N)`, where N is an integer constant expression between 1 (unsigned) or 2 (signed) and BITINT_MAXWIDTH, inclusive) *and* extended integer types wider than `long long` to not fit in intmax_t / uintmax_t any more, for those ABI concerns.
21:44:23 <fizzie> Oh, it's slightly more subtle than that for the extended integer types.
21:45:07 <fizzie> N3096 7.22.1.5p1: "The [intmax_t type] designates a signed integer type -- capable of representing any value of any signed integer type with the possible exceptions of signed bit-precise integer types and of signed extended integer types that are wider than `long long` and that are referred by the type definition for an exact width integer type[.]"
21:45:48 <fizzie> So an implementation might now define `int128_t` using an extended integer type (say, `__int128`) while still having a 64-bit `intmax_t`.
21:46:29 <b_jonas> so they fixed the rule about intmax_t in newer C standards, that's good to know
22:04:07 <b_jonas> perhaps the problem is that imaxdiv should never have been a function, it should have been a function-like macro that expands to a function call
22:04:28 <b_jonas> and similar for imaxabs etc
22:05:44 <b_jonas> that only works if the C standard explicitly allowed that for just those few functions
22:06:23 <b_jonas> oh yeah, and printf shouldn't have gained "%jd" conversion, the size flag should've been a macro like it is for int64_t etc
22:07:28 <b_jonas> we have that kind of nonsense already about file offset types on x86_32
22:09:17 <b_jonas> at this point they'll have to standardize a new type alias like int_really_max_t and function names and printf conversion letter macros for that type
22:15:48 <b_jonas> (they'd probably choose a more dignified-sounding name, like int_widest_t, over int_really_max_t though)
22:20:28 <fizzie> Debian's doing a pretty disruptive transition to 64-bit `time_t` type on the 32-bit platforms, and it's affecting the other architectures too because of something about how Debian packaging works (it's a change in SONAME, and those are shared for all outputs from the same source package, or something along those lines).
22:21:17 <fizzie> https://wiki.debian.org/ReleaseGoals/64bit-time
22:22:15 <ais523> it's less disruptive than the year 2038 bug would be if not fixed, though
22:22:23 <b_jonas> sigbovik proceedings are out
22:22:41 <ais523> I am still worried about that, it seems likely to be much worse than the Y2K bug and people will be more complacent this time given how last time went relatively smoothly
22:23:21 <ais523> (after a huge amount of effort to prepare)
22:24:19 <b_jonas> yes, but much fewer x86_32 will be running by then
22:25:04 <ais523> I'm more worried about 64-bit programs that are using 32-bit time_t for compatibility with existing file formats
22:27:18 <b_jonas> I'm worried about the FAT file system, that will still be in use in year 2107 by stuff like digital cameras and cash registers, and there'll be no single accepted way to extend the mtime field to larger than the current size, because Windows 95 OSR2 decided to use up ALL THE REMAINING BYTES in the directory entry
22:28:02 <ais523> I thought those were mostly at least using FAT32
22:28:11 <ais523> but, maybe that also has 32-bit mtime
22:29:34 <b_jonas> we can replace our most common CPU architecture two more times over by then, but FAT will still be present
22:29:53 <b_jonas> CPU arch together with ABI I mean
22:31:23 <b_jonas> but yes, also some other file formats
22:32:15 <b_jonas> heck, it'll be like https://xkcd.com/865/ , human civilization is all gone, but its successor can't get rid of some of our file formats
22:35:14 <b_jonas> http://www.sigbovik.org/2024/proceedings.pdf
22:48:41 -!- Sgeo has joined.
23:24:38 -!- Soni has quit (Remote host closed the connection).
23:26:11 -!- SoniEx2_ has joined.
23:46:34 <b_jonas> oh jesus. Tom7 did this in so much more of the Tom7 way than was apparent from his short presentation