< 1712536501 903268 :Noisytoot!~noisytoot@user/meow/Noisytoot QUIT :Excess Flood < 1712536570 810411 :Noisytoot!~noisytoot@user/meow/Noisytoot JOIN #esolangs Noisytoot :Ron < 1712536807 647009 :Noisytoot!~noisytoot@user/meow/Noisytoot QUIT :Excess Flood < 1712536840 425544 :Noisytoot!~noisytoot@user/meow/Noisytoot JOIN #esolangs Noisytoot :Ron < 1712539138 705506 :ais523!~ais523@user/ais523 QUIT :Quit: quit < 1712545200 499190 :Taneb!~Taneb@2001:41c8:51:10d:aaaa:0:aaaa:0 QUIT :Quit: I seem to have stopped. < 1712545272 162164 :Taneb!~Taneb@2001:41c8:51:10d:aaaa:0:aaaa:0 JOIN #esolangs Taneb :Nathan van Doorn < 1712546315 225110 :Noisytoot!~noisytoot@user/meow/Noisytoot QUIT :Ping timeout: 264 seconds < 1712548185 159045 :Noisytoot!~noisytoot@user/meow/Noisytoot JOIN #esolangs Noisytoot :Ron < 1712548371 380072 :Noisytoot!~noisytoot@user/meow/Noisytoot QUIT :Client Quit < 1712548687 652565 :Noisytoot!~noisytoot@user/meow/Noisytoot JOIN #esolangs Noisytoot :Ron > 1712550555 78742 PRIVMSG #esolangs :14[[07Brainfuck14]]4 10 02https://esolangs.org/w/index.php?diff=125964&oldid=125946 5* 03EvyLah 5* (+101) 10><> implementation < 1712550856 677760 :Noisytoot!~noisytoot@user/meow/Noisytoot QUIT :Ping timeout: 268 seconds > 1712551138 819381 PRIVMSG #esolangs :14[[07Hi14]]4 10 02https://esolangs.org/w/index.php?diff=125965&oldid=119779 5* 03EvyLah 5* (+202) 10><> + brainfuck implementation > 1712551439 94814 PRIVMSG #esolangs :14[[077 bytes XD14]]4 10 02https://esolangs.org/w/index.php?diff=125966&oldid=113716 5* 03EvyLah 5* (+80) 10 < 1712556002 710806 :Sgeo!~Sgeo@user/sgeo QUIT :Read error: Connection reset by peer < 1712557751 522857 :visilii!~visilii@188.254.110.118 PRIVMSG #esolangs :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 < 1712557769 648756 :visilii!~visilii@188.254.110.118 PRIVMSG #esolangs :I'm kinda new to the whole esoteric language thing and the amount of different esolangs is astounding to me! < 1712558595 806895 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User > 1712558834 90423 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03Xyper 5* 10New user account > 1712560114 749441 PRIVMSG #esolangs :14[[07Special:Log/newusers14]]4 create10 02 5* 03RemTwo 5* 10New user account < 1712560211 247445 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1712560385 615366 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User < 1712563677 135781 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1712565853 27974 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712565958 220422 :int-e!~noone@int-e.eu PRIVMSG #esolangs :witness the power of procrastination < 1712566020 83323 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :the central conceit that is; I don't mind if the other three twists that I thought about for are taken: < 1712566091 414199 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :(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 < 1712566176 978522 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :(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 < 1712566333 722042 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :(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 < 1712566339 728664 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712566989 441898 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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« < 1712567178 495068 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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. < 1712567288 536117 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Hmm C is trying so hard though < 1712567628 912132 :int-e!~noone@int-e.eu PRIVMSG #esolangs :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. < 1712567926 93742 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User < 1712568944 287518 :int-e!~noone@int-e.eu PRIVMSG #esolangs :It does not. It also fails to verify a signature even though libsodium does like it... but that may still be my fault. < 1712569101 428722 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712569107 405943 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712569113 483656 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :displaying colored graphics so it's not real C" crowd that keep enforcing the signed shift undefined thing < 1712569339 926468 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712569345 878679 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :operations like shifting a number that your CPU can already do anyway < 1712569351 546295 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :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. < 1712569443 177116 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712569507 501399 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712569559 294434 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712569578 429016 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but if you make a clean interface where the program will fail to compile on those compilers then it's fine < 1712569616 135761 :int-e!~noone@int-e.eu PRIVMSG #esolangs :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. < 1712569851 339673 :user3456!user3456@user/user3456 QUIT :Quit: I use ZNC - https://znc.in < 1712569865 465228 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712569871 509914 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :they'll probably laugh me off unless I make a full repro. < 1712569922 677882 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712570060 356842 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :wait, I didn't say the fun part < 1712570150 500996 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712570156 584907 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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) < 1712571002 316597 :user3456!~user3456@user/user3456 JOIN #esolangs user3456 :user3456 < 1712571387 37182 :user3456!~user3456@user/user3456 QUIT :Ping timeout: 252 seconds < 1712571516 531575 :user3456!user3456@user/user3456 JOIN #esolangs user3456 :user3456 < 1712572141 629889 :int-e!~noone@int-e.eu PRIVMSG #esolangs :It was my fault. < 1712572196 631628 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(The failure to verify a signature that is; the shifting negative numbers right thing is real.) < 1712572488 284613 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 JOIN #esolangs Lord_of_Life :Lord < 1712572530 371 :Lord_of_Life!~Lord@user/lord-of-life/x-2819915 QUIT :Ping timeout: 256 seconds < 1712572569 944816 :Lord_of_Life_!~Lord@user/lord-of-life/x-2819915 NICK :Lord_of_Life < 1712573029 744657 :Noisytoot!~noisytoot@user/meow/Noisytoot JOIN #esolangs Noisytoot :Ron < 1712573307 91288 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu JOIN #esolangs b_jonas :[https://web.libera.chat] wib_jonas < 1712573391 114953 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :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. < 1712573436 252724 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :and then you have to deal with three-input FMA instructions, newer instructions that have two input and a separate output operand, and more. < 1712573619 408701 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :int-e: wait, is that the size-reduced cryptography source code thing? < 1712573656 283136 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :I didn't realize that because it has "tweet" instead of "t-shirt" or "tattoo" in its name < 1712573718 912445 :int-e!~noone@int-e.eu PRIVMSG #esolangs :it's "tweet" because they tweeted it out as a series of tweets < 1712574054 609269 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :right < 1712574730 819460 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :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 < 1712574731 306676 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu PRIVMSG #esolangs :thing UB" message on that. that, or maybe a crypto protocol tunneled through twitter. > 1712574955 353776 PRIVMSG #esolangs :14[[07User talk:None114]]4 M10 02https://esolangs.org/w/index.php?diff=125967&oldid=125880 5* 03None1 5* (+196) 10 > 1712575413 600697 PRIVMSG #esolangs :14[[07Fairytale14]]4 10 02https://esolangs.org/w/index.php?diff=125968&oldid=125958 5* 03Leomok2009 5* (+14) 10Fixed mistake in translated code > 1712575453 255868 PRIVMSG #esolangs :14[[07Fairytale14]]4 10 02https://esolangs.org/w/index.php?diff=125969&oldid=125968 5* 03Leomok2009 5* (+8) 10 < 1712575515 42465 :amby!~ambylastn@31.205.89.228 JOIN #esolangs amby :realname < 1712578902 320999 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) > 1712579204 30396 PRIVMSG #esolangs :14[[07Anti-Machine language14]]4 10 02https://esolangs.org/w/index.php?diff=125970&oldid=125842 5* 03Cleverxia 5* (+223) 10/* Implementations (?) */ < 1712580705 407152 :ais523!~ais523@user/ais523 QUIT :Remote host closed the connection < 1712580778 885354 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1712581382 343852 :ais523!~ais523@user/ais523 QUIT :Remote host closed the connection < 1712581455 237917 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) > 1712581833 154961 PRIVMSG #esolangs :14[[07Do while true14]]4 N10 02https://esolangs.org/w/index.php?oldid=125971 5* 03Cleverxia 5* (+1492) 10Created 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 < 1712583324 184011 :ais523!~ais523@user/ais523 QUIT :Ping timeout: 268 seconds < 1712583961 671467 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) > 1712586243 490076 PRIVMSG #esolangs :14[[07JustWords14]]4 10 02https://esolangs.org/w/index.php?diff=125972&oldid=123728 5* 03Kaveh Yousefi 5* (+473) 10Supplemented an alternative truth-machine implementation, as well as two further example programs. > 1712586331 52798 PRIVMSG #esolangs :14[[07JustWords14]]4 10 02https://esolangs.org/w/index.php?diff=125973&oldid=125972 5* 03Kaveh Yousefi 5* (+249) 10Added a hyperlink to my implementation of the JustWords programming language on GitHub and supplemented two page categories. < 1712587332 387828 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1712589049 16020 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User < 1712589412 849186 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot QUIT :Quit: ZNC 1.8.2+deb3.1 - https://znc.in < 1712589412 969885 :simcop2387!~simcop238@perlbot/patrician/simcop2387 QUIT :Quit: ZNC 1.8.2+deb3.1 - https://znc.in < 1712589668 104119 :__monty__!~toonn@user/toonn JOIN #esolangs toonn :Unknown < 1712590552 881660 :simcop2387!~simcop238@perlbot/patrician/simcop2387 JOIN #esolangs simcop2387 :ZNC - https://znc.in < 1712590670 188333 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot JOIN #esolangs perlbot :ZNC - https://znc.in < 1712593703 816270 :simcop2387!~simcop238@perlbot/patrician/simcop2387 QUIT :Read error: Connection reset by peer < 1712593703 937780 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot QUIT :Read error: Connection reset by peer < 1712594006 705452 :wib_jonas!~wib_jonas@business-37-191-60-209.business.broadband.hu QUIT :Quit: Client closed < 1712594062 317321 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot JOIN #esolangs perlbot :ZNC - https://znc.in < 1712594095 312232 :simcop2387!~simcop238@perlbot/patrician/simcop2387 JOIN #esolangs simcop2387 :ZNC - https://znc.in < 1712594419 434489 :integral_!sid296274@user/integral JOIN #esolangs integral :bsmith < 1712594543 816335 :integral!sid296274@user/integral QUIT :Ping timeout: 268 seconds < 1712594544 972803 :b_jonas!~x@88.87.242.184 QUIT :Ping timeout: 268 seconds < 1712594546 848060 :Hooloovoo!~Hooloovoo@hax0rbana.org QUIT :Ping timeout: 268 seconds < 1712594547 266211 :integral_!sid296274@user/integral NICK :integral < 1712594569 170909 :b_jonas!~x@88.87.242.184 JOIN #esolangs * :b_jonas < 1712594594 657308 :Hooloovoo!~Hooloovoo@hax0rbana.org JOIN #esolangs hooloovoo :ZNC - https://znc.in < 1712595056 585553 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1712595095 273321 :simcop2387!~simcop238@perlbot/patrician/simcop2387 QUIT :Read error: Connection reset by peer < 1712595095 450965 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot QUIT :Read error: Connection reset by peer < 1712595394 329011 :perlbot!~perlbot@perlbot/bot/simcop2387/perlbot JOIN #esolangs perlbot :ZNC - https://znc.in < 1712595422 334135 :simcop2387!~simcop238@perlbot/patrician/simcop2387 JOIN #esolangs simcop2387 :ZNC - https://znc.in < 1712595645 985743 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :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 < 1712595736 335005 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :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) < 1712595752 820302 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :like, probably my first thought was increment/decrement and then I wasn't sure that would work < 1712595786 724520 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :as for the two's complement argument, I don't understand why shifts weren't just defined arithmetically < 1712595846 96303 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :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) < 1712595873 752984 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :
ACTION wonders whether, if multiplication is * and exponentiation is **, tetration should be ***
< 1712595916 18528 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :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 < 1712595922 534395 :int-e!~noone@int-e.eu PRIVMSG #esolangs :ais523: but 1-s complement!!!1eleven < 1712595942 244378 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :1's complement can implement that < 1712595945 987618 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :That "arithmetic" definition is how it *is* defined. < 1712595952 985032 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :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." < 1712595955 51111 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it doesn't correspond to a single machine instruction, but it can implement it < 1712595976 700500 :int-e!~noone@int-e.eu PRIVMSG #esolangs :but then the 1s complement left shift is different for unsigned and signed < 1712595980 650576 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fizzie: ah, that makes the 1's complement versus 2's complement even weirder < 1712596020 624269 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :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." < 1712596028 670240 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fizzie: oh, no, haha, "reduced modulo one more than the maximum value representable in the result type" < 1712596039 383138 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so it provides different answers in 1's complement and 2's complement systems < 1712596039 559878 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User < 1712596043 198044 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but then, I guess so does addition < 1712596052 811129 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or, hmm < 1712596057 717901 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :That's for unsigned types only. < 1712596064 780426 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :all-bits-1 is a valid nonzero unsigned number even in 1's complement systems, isn't it < 1712596077 443350 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :no wonder people stopped using them, they don't handle unsigned numbers at all well < 1712596169 665652 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :so the maximum value representable is there to handle padding bits, I guess (which for all I know are also banned for unsigned numbers) < 1712596195 970712 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :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 < 1712596211 850565 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :e.g. you have 66-bit registers in your otherwise 64-bit processor < 1712596239 977208 :int-e!~noone@int-e.eu PRIVMSG #esolangs :is this for carries and overflows? < 1712596240 647378 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and the memory read operations specify bitwidth and sign-/zero-extension, the memory write operations specify bitwidth and signed saturation / unsigned saturation / wrapping < 1712596251 603018 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's to entirely replace all uses of flags < 1712596265 261755 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :instead of branching on a flag, you branch on the high bits of a register < 1712596276 204800 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and this means that the processor doesn't have a global variable it needs to track any more < 1712596284 375618 :int-e!~noone@int-e.eu PRIVMSG #esolangs :"all uses of flags" hmm, I wonder whether anybody ever uses Intel's parity flag. < 1712596295 426657 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :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. < 1712596297 760115 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :well, you can just look at the low bits for that one < 1712596309 619349 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :although, the x86 parity flag isn't very useful because it just takes the parity of the bottom 8 bits of the result < 1712596343 331284 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :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)." < 1712596352 158655 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :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 < 1712596374 706832 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :Which allows the M = N case, where the signed type has the same value bits as the corresponding unsigned type. < 1712596391 690895 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :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? < 1712596405 63167 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess it's probably "rather than" < 1712596406 712537 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :It's considered a sign bit. < 1712596442 228800 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :("-- 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.") < 1712596485 430570 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I guess the sign bit isn't required to be at the top < 1712596497 502290 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :C probably doesn't care about bit order at all, it's hard to observe < 1712596507 843832 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(byte order is observable in C, though) < 1712596514 358692 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :"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/)." < 1712596573 300938 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fwiw, I vaguely remember sign-magnitude being invented first, then one's complement, then two's complement < 1712596612 739149 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :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 < 1712596638 561401 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(the main issue is with INT_MIN, which isn't symmetrical to INT_MAX) < 1712596647 538889 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :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. < 1712596655 884792 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :If it is, then the range is of course symmetrical. < 1712596657 143658 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or the infamous INT_MIN/-1 overflow which is the only case where a division by a number other than 0 can overflow < 1712596670 442911 :int-e!~noone@int-e.eu PRIVMSG #esolangs :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. < 1712596686 661462 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Hmm s/various/a number of/ would've been punnier. < 1712596688 641121 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fizzie: there are definitely some advantages to 1000…000 trap representation, but also some disadvantages, and I think it never really caught on < 1712596700 428315 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's a trap representation for floats too, isn't it? or at least some sort of NaN? < 1712596767 125406 :int-e!~noone@int-e.eu PRIVMSG #esolangs :"is just weird to me" - what is this representation actually good at? < 1712596797 12625 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :ah no, it's -0 < 1712596818 724177 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :which is not a trap representation or even a particularly badly-behaving number, although it's weird < 1712596843 992040 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: it's better than sign-magnitude, it has most but not all the advantages of two's complement < 1712596847 372187 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :and I think it was invented first < 1712596981 793205 :int-e!~noone@int-e.eu PRIVMSG #esolangs :I guess there are tricks like feeding in the sign bit as a carry for addition that make one-s complement tolerable. < 1712596991 259963 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :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. < 1712597029 843688 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :int-e: here's what I was thinking of: https://en.wikipedia.org/wiki/Pascal%27s_calculator#9's_complement < 1712597047 813881 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :was invented in 1642, I think that easily beats 2's complement :-) < 1712597060 937052 :int-e!~noone@int-e.eu PRIVMSG #esolangs :and I guess xor-with-sign is a good way to prepare for full precision multiplication < 1712597069 287187 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :fizzie: this means that -0 is actually the additive identity < 1712597076 845755 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :because it'll decay when added to 0, but not to another -0 < 1712597144 412491 :int-e!~noone@int-e.eu PRIVMSG #esolangs :So okay, maybe overall that makes it slightly better than sign-magnitude. < 1712597189 699381 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :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 < 1712597195 634050 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :Not working particularly well, alas. < 1712597207 775422 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :Still fun to play with. < 1712597215 704881 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(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) < 1712597292 542479 :int-e!~noone@int-e.eu PRIVMSG #esolangs :oh color coding on the wheels? neat < 1712598181 158801 :ais523!~ais523@user/ais523 QUIT :Quit: playing a bridge tournament < 1712600298 636694 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712600305 57242 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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. < 1712600471 397149 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"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 < 1712600477 794006 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :bit for the accumulator, in particular the carry bit is 1 when there's no unsigned overflow on a *subtraction*, unlike on x86. < 1712600584 606828 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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). < 1712600634 33370 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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. < 1712600669 416347 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :int-e: parity flag => I think back in the early PC days people used it for serial port communication. < 1712600729 290855 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"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 < 1712600771 268200 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"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 < 1712600946 59303 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"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 < 1712600969 656430 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :like think of the Babbage thing < 1712601043 109989 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"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. < 1712601144 213990 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"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. < 1712601224 57125 :int-e!~noone@int-e.eu PRIVMSG #esolangs :`? agc < 1712601226 804233 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :agc? ¯\(°​_o)/¯ < 1712601229 574160 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :"this means that -0 is actually the additive identity" => wait, there were computers that did that for integers too? now that's messed up. < 1712601229 916286 :int-e!~noone@int-e.eu PRIVMSG #esolangs :oh the apollo thing < 1712601278 575475 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :the mechanical calculators that I've seen are ten's complement, not nines' complement. even some early digital calculators are. < 1712601296 792428 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :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. < 1712601299 181999 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :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)." < 1712601300 117454 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :int-e: https://esolangs.org/wiki/Apollo_Guidance_Computer < 1712601302 264993 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :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. < 1712601330 586440 :int-e!~noone@int-e.eu PRIVMSG #esolangs :b_jonas: Yeah I looked it up recently actually, just didn't recall immediately. < 1712601341 336399 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(You mentioned it before.) < 1712601346 375798 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :fizzie: which standard are you looking at, just to be clear? C99? < 1712601385 374867 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :C11 (the N1570 draft), which is for some reason the one I've settled on as a default. < 1712601405 690730 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that's fine, I just didn't want to have to compare multiple standards for this < 1712601407 813859 :int-e!~noone@int-e.eu PRIVMSG #esolangs :mostly the C standard has to ensure that copying bytes of in-memory objects preserves their values < 1712601457 839846 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :totality in the solar eclipse is now mostly in the US < 1712601458 310928 :int-e!~noone@int-e.eu PRIVMSG #esolangs :if bytes had padding then that would become awkward < 1712601506 523418 :int-e!~noone@int-e.eu PRIVMSG #esolangs :the sun is totally eclipsed by the Earth here < 1712601588 590606 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :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." < 1712601629 131189 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :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. < 1712601635 207915 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1712601644 829881 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :Except at least here it's rainy and very overcast. < 1712601690 237992 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yes, Scotland will have a rather unimpressive partial eclipse < 1712601769 408729 :int-e!~noone@int-e.eu PRIVMSG #esolangs :hmm... we're past equinox so being further north helps too? < 1712601800 607590 :int-e!~noone@int-e.eu PRIVMSG #esolangs :not sure how significant that is < 1712601804 219036 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :Yes. Though UK also leans west, so going "north" helps with that too. < 1712601828 824413 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(it's only been 3 weeks) < 1712601953 958544 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :We went to Isle of Skye once. Looking up a map, they'll have a 22.4% of an eclipse. < 1712601963 218672 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :Well, I guess any amount counts as "an eclipse", but still. < 1712602008 176100 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User < 1712602183 94743 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :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? < 1712602269 772967 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :" ... 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 < 1712602345 436601 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :" 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? < 1712602415 640209 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :zzo38: that must depend on the other protocol that you want to distinguish from TLS < 1712602464 446617 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712602512 402993 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712602550 255424 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I don't know how this works for DNS for example < 1712603008 926664 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1712603029 67530 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :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). < 1712603050 393263 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :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. < 1712603077 57345 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl JOIN #esolangs * :Textual User < 1712604121 592614 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I know HTTP and IRC have separate port numbers for TLS versus don-TLS, but I don't know why < 1712604403 190475 :int-e!~noone@int-e.eu PRIVMSG #esolangs :simpler design < 1712604405 746893 :int-e!~noone@int-e.eu PRIVMSG #esolangs :
ACTION shrugs
< 1712604428 96428 :int-e!~noone@int-e.eu PRIVMSG #esolangs :there's the whole starttls mess too < 1712604903 918949 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :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. < 1712604943 993843 :zzo38!~zzo38@host-24-207-52-143.public.eastlink.ca PRIVMSG #esolangs :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). < 1712605026 96441 :Noisytoot!~noisytoot@user/meow/Noisytoot PRIVMSG #esolangs :IRC has STARTTLS: https://ircv3.net/specs/deprecated/tls.html, it's just that nothing supports it and it's deprecated < 1712605202 437568 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :should I have chosen an eclipse-related password of the month? or would that have been boring? < 1712605219 603993 :int-e!~noone@int-e.eu PRIVMSG #esolangs :There's an old internet draft for telnet too: https://datatracker.ietf.org/doc/html/draft-ietf-tn3270e-telnet-tls-02 < 1712605222 477315 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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. < 1712605248 656632 :int-e!~noone@int-e.eu PRIVMSG #esolangs :b_jonas: Yeah is the program available anywhere? < 1712605459 883444 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :int-e: I don't know, but there were very few live presentations. the video should still be available on twitch.tv < 1712605472 30333 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :there'll be much more articles in the proceedings than presentations < 1712605485 389292 :int-e!~noone@int-e.eu PRIVMSG #esolangs :But I don't want to go through a video. < 1712605515 795768 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :int-e: should I summarize tom7's presentation? < 1712605635 84021 :int-e!~noone@int-e.eu PRIVMSG #esolangs :Not really... I'm more interested in a list of contributions. I'll wait. < 1712607253 603617 :int-e!~noone@int-e.eu PRIVMSG #esolangs :This will do the trick for now: https://github.com/sigbovik/sigbovik/blob/20e0e2d7cddf2357d8a288a9116461c2d2621ee6/papers.tex < 1712607280 924651 :int-e!~noone@int-e.eu PRIVMSG #esolangs :(the papers are in the repo too, but I really wanted a table of contents) < 1712607734 701568 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712607740 781024 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :the type alias uint1_t for bool? < 1712607978 491405 :int-e!~noone@int-e.eu PRIVMSG #esolangs :b_jonas: the C++ thing makes more sense though seeing how true + true becomes true when casted back to a bool. < 1712608006 157853 :int-e!~noone@int-e.eu PRIVMSG #esolangs :rather than doing arithmetic modulo 2. < 1712608138 873966 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712608169 500376 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :hmm wait < 1712608267 883540 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yeah, it seems like the text does want to allow that < 1712608305 340781 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that probably actually makes sense for a sign-magnitude computer < 1712608316 55500 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :I didn't know this, thank you < 1712609629 990242 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712609635 982736 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :hypothetical computer with weird integer types the result could be a signed long. < 1712609689 581205 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but I might be getting that wrong, don't trust me on taht < 1712609735 24028 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1712609894 40250 :ais523!~ais523@user/ais523 QUIT :Read error: Connection reset by peer < 1712609920 16666 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1712610335 390996 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :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 < 1712611061 833604 :ais523!~ais523@user/ais523 QUIT :Remote host closed the connection < 1712611086 41259 :ais523!~ais523@user/ais523 JOIN #esolangs ais523 :(this is obviously not my real name) < 1712611396 730984 :tromp!~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl QUIT :Quit: My iMac has gone to sleep. ZZZzzz… < 1712611632 492175 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712611638 944325 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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. < 1712611788 592204 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :b_jonas: I read a good blog post about this recently < 1712611801 876600 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :here we go: https://thephd.dev/intmax_t-hell-c++-c < 1712611821 748156 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :ais523: thank you > 1712611832 642846 PRIVMSG #esolangs :14[[07Compaline14]]4 10 02https://esolangs.org/w/index.php?diff=125974&oldid=118090 5* 03Ice Bird 5* (+3219) 10 > 1712611876 212542 PRIVMSG #esolangs :14[[07Compaline14]]4 10 02https://esolangs.org/w/index.php?diff=125975&oldid=125974 5* 03Ice Bird 5* (+39) 10 > 1712612009 55252 PRIVMSG #esolangs :14[[07Compaline14]]4 10 02https://esolangs.org/w/index.php?diff=125976&oldid=125975 5* 03Ice Bird 5* (-27) 10 > 1712612025 209641 PRIVMSG #esolangs :14[[07Compaline14]]4 10 02https://esolangs.org/w/index.php?diff=125977&oldid=125976 5* 03Ice Bird 5* (+2) 10 > 1712612129 658783 PRIVMSG #esolangs :14[[07Compaline14]]4 10 02https://esolangs.org/w/index.php?diff=125978&oldid=125977 5* 03Ice Bird 5* (+6) 10 < 1712612324 669709 :__monty__!~toonn@user/toonn QUIT :Quit: leaving < 1712612581 294077 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :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. < 1712612663 710498 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :Oh, it's slightly more subtle than that for the extended integer types. < 1712612707 511617 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :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[.]" < 1712612748 158771 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :So an implementation might now define `int128_t` using an extended integer type (say, `__int128`) while still having a 64-bit `intmax_t`. < 1712612771 98651 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :fizzie: nice < 1712612789 175525 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :so they fixed the rule about intmax_t in newer C standards, that's good to know < 1712613847 367011 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712613868 940246 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :and similar for imaxabs etc < 1712613944 90100 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :that only works if the C standard explicitly allowed that for just those few functions < 1712613983 604335 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712614048 700785 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :we have that kind of nonsense already about file offset types on x86_32 < 1712614157 680392 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712614548 625688 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :(they'd probably choose a more dignified-sounding name, like int_widest_t, over int_really_max_t though) < 1712614828 410977 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :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). < 1712614877 612090 :fizzie!~irc@selene.zem.fi PRIVMSG #esolangs :https://wiki.debian.org/ReleaseGoals/64bit-time < 1712614935 539168 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :it's less disruptive than the year 2038 bug would be if not fixed, though < 1712614943 194080 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :sigbovik proceedings are out < 1712614949 156754 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :int-e: sigbovik < 1712614961 996008 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :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 < 1712615001 676853 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :(after a huge amount of effort to prepare) < 1712615059 367900 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :yes, but much fewer x86_32 will be running by then < 1712615104 746455 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I'm more worried about 64-bit programs that are using 32-bit time_t for compatibility with existing file formats < 1712615112 396319 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :or wire formats < 1712615238 589352 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712615282 326445 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :I thought those were mostly at least using FAT32 < 1712615291 279684 :ais523!~ais523@user/ais523 PRIVMSG #esolangs :but, maybe that also has 32-bit mtime < 1712615331 718402 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :this is for FAT32 < 1712615374 353191 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :we can replace our most common CPU architecture two more times over by then, but FAT will still be present < 1712615393 402956 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :CPU arch together with ABI I mean < 1712615483 878862 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :but yes, also some other file formats < 1712615535 269194 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :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 < 1712615714 933695 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :http://www.sigbovik.org/2024/proceedings.pdf < 1712615719 973914 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :`? sigbovik < 1712615722 658447 :HackEso!~h@techne.zem.fi PRIVMSG #esolangs :sigbovik? ¯\(°​_o)/¯ < 1712616521 176607 :Sgeo!~Sgeo@user/sgeo JOIN #esolangs Sgeo :realname < 1712618678 700741 :Soni!~quassel@sodapop.autistic.space QUIT :Remote host closed the connection < 1712618771 345829 :SoniEx2_!~quassel@sodapop.autistic.space JOIN #esolangs SoniEx2 :Genders: Autgender, 💜🖤💚; Soni L. < 1712619994 939450 :b_jonas!~x@88.87.242.184 PRIVMSG #esolangs :oh jesus. Tom7 did this in so much more of the Tom7 way than was apparent from his short presentation