00:00:21 -!- tromp has joined. 00:17:26 @metar ENVA 00:17:28 ENVA 212350Z 18011KT CAVOK 01/M04 Q1024 RMK WIND 670FT 21018KT 00:21:35 `` doag | grep '> #' | awk '{print $2}' 00:21:38 ​ \ \ \ \ \ 00:24:14 `doag src/hello3.c 00:24:16 11756:2019-03-21 # Preserve fizzie\'s repaired version//`mk src/hello3.c//const char main[] = "%0000%HELOPPPPPPT]5Hell1E XP5o wo1E$XP5rld!1E(XP4@4J1E,4@4GPZ$AP_^^^^T^\\x0f\\x05XX\\xc3"; 00:24:46 `` doag | grep '> #' | grep copp 00:24:48 1181:2012-12-18 addquote < zzo38> What is portable way of load/save floating points in files, using a C code? < kmc> #ifndef __STDC_IEC_559__ #error Here\'s a nickel, kid. Buy a real computer. #endif 00:24:57 aha 00:25:13 i don't think coppro has used that nick since i added `# 00:29:20 -!- Lord_of_Life_ has joined. 00:31:52 -!- Lord_of_Life has quit (Ping timeout: 250 seconds). 00:31:54 -!- Lord_of_Life_ has changed nick to Lord_of_Life. 00:33:36 hehe I'm happy with that quote 00:33:42 it stands the test of time 00:42:38 -!- tromp has quit (Remote host closed the connection). 00:46:51 `sled src/hello3.c//s/x0f/17/;s/x05/5/;s/xc3/303/ 00:46:53 src/hello3.c//const char main[] = "%0000%HELOPPPPPPT]5Hell1E XP5o wo1E$XP5rld!1E(XP4@4J1E,4@4GPZ$AP_^^^^T^\17\5XX\303"; 01:34:06 fizzie: i advertized that on PPCG's chat 01:34:22 (s?) 01:34:32 s. 01:34:43 i just found a known working MC88110 for sale. 01:34:46 yes 01:34:51 * moony celebrate 01:36:50 ^celebrate 01:36:50 \o| c.c \o/ ಠ_ಠ \m/ \m/ \o_ c.c _o/ \m/ \m/ ಠ_ಠ \o/ c.c |o/ 01:37:33 not the same since the monqy exodus. 01:38:25 `? monqy 01:38:26 monqy is no longer extant. He lives in concept, hidden, unfindable. You could ask itidus21 for details, if you find him. 01:38:42 hm i think i may be confusing people 01:38:56 `grwp feet 01:38:58 limerick:A limerick is a verse with two left metrical feet and three right metrical feet. \ myndzi:myndzi used to keep us all on our feet. 01:39:05 myndzi it was. 01:39:20 oerjan: I've been working on a "proper" printable version, in the something that fits in the same 'const char main[]' form but uses only valid UTF-8 printable Unicode characters (to make 'ret' available). 01:39:27 But since it can't use syscall (0f 05 is just not okay), it's a lot more complicated. I have a non-printable version now for looking up "puts" and "exit" via ELF auxiliary vector -> program header -> PT_DYNAMIC section -> DT_DEBUG entry -> struct link_map list of linked libs -> string/symbol tables of all loaded libraries. 01:39:36 It's already 214 bytes without any work to make it printable. 01:40:09 is it cheating to use the dynamic linker? 01:40:15 because you could look for a PLT entry 01:40:18 yes 01:40:21 mm 01:40:28 I think it is 01:40:29 there's also a syscall instruction in the VDSO isn't there 01:40:37 kmc: Not in x86-64 any more. 01:40:44 or... you could just scan all of +x memory for 0f 05 01:40:48 kmc: Or, I mean, yes, there's three syscall instructions, but not one just for calling. 01:40:58 fizzie: but you can jump to any point can't you 01:41:02 you’ve read the tom7 printable compiler paper right? 01:41:04 i guess it might be hard to get control back 01:41:06 oh yes 01:41:15 tom7 is a mad genius 01:41:19 kmc: Yes, but there's usually annoying code after, and in any case it doesn't feel right relying on those sort of offsets. 01:41:28 fizzie: well, fair enough 01:41:33 Scanning memory for the right thing would presumably work though. 01:42:48 . o O ( until the compilers start putting in traps to prevent it ) 01:43:28 Also, I gave some thought about using the int 0x80 syscall interface, because "int 0x80" is printable (U+0340 COMBINING GRAVE TONE MARK), but the problem with that is that there's no mappings below the 2G limit, and that thing's "write" can only push through 32 bits of pointers. 01:43:29 or kernels, whatever 01:44:04 And the mmap syscall on x86-32 takes the arguments packed into a struct, so you'd need a pointer in order to get some memory you can point at. 01:47:02 can't you use the stack for that, though? 01:47:29 No, because the stack is somewhere around 0x7ffe70532000. 01:48:01 So a pointer to something on it would get truncated. 01:48:27 I mean, it's very arbitrary that I'm trying to make this a x86-64 binary. If I just compiled it with -m32, it'd be simple. 01:49:14 ah yeah 01:49:38 and you're not allowed to define any symbols but 'main', right? 01:49:59 Well, it's not like there's a law. But that's what I've been operating under. 02:32:43 -!- zestymug has quit (Ping timeout: 256 seconds). 02:36:58 -!- FreeFull has quit. 02:37:13 [[Special:Log/newusers]] create * W3Rn1ckz * New user account 02:40:06 [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=60556&oldid=60540 * W3Rn1ckz * (+258) /* Introductions */ 03:14:52 [[Functasy]] M https://esolangs.org/w/index.php?diff=60557&oldid=60552 * Hakerh400 * (-43) /* Advanced examples */ 03:37:48 -!- izabera has changed nick to redbutt. 03:54:04 -!- danieljabailey has joined. 03:56:19 -!- redbutt has changed nick to izabera. 04:31:33 -!- ^[ has quit (Ping timeout: 250 seconds). 04:32:07 -!- ProofTechnique has quit (Ping timeout: 240 seconds). 04:33:08 -!- dingwat has quit (Ping timeout: 268 seconds). 04:34:25 -!- ProofTechnique has joined. 04:34:25 -!- ^[ has joined. 04:36:06 -!- dingwat has joined. 04:47:38 -!- oerjan has quit (Quit: Nite). 04:51:47 -!- tromp has joined. 04:56:39 -!- tromp has quit (Ping timeout: 268 seconds). 05:56:32 -!- danieljabailey has quit (Ping timeout: 244 seconds). 06:40:07 -!- tromp has joined. 06:44:23 -!- tromp has quit (Ping timeout: 252 seconds). 07:47:48 " If I just compiled it with -m32, it'd be simple." => no, it wouldn't be, because HackEso doesn't have the necessary system headers installed so you can't easily compile to x86_32 with gcc with the default options 08:02:31 -!- tromp has joined. 08:15:24 "And the mmap syscall on x86-32 takes the arguments packed into a struct" => are you sure? because it only has six arguments, and the linux man-pages don't mention that. can you use the ipc system call to map a sysvipc shared memory segment instead? 08:17:37 I think it's the socket syscalls that take argument the way you describe: http://man7.org/linux/man-pages/man2/socketcall.2.html 08:21:06 fizzie: and http://man7.org/linux/man-pages/man2/syscall.2.html confirms that syscalls take up to six arguments on x86_32 08:21:17 with the int80 interface 08:23:25 http://man7.org/linux/man-pages/man2/mmap.2.html and http://man7.org/linux/man-pages/man2/mmap2.2.html describe the specific syscall 09:03:56 -!- b_jonas has quit (Quit: leaving). 09:05:34 -!- tromp has quit (Remote host closed the connection). 09:30:05 -!- arseniiv has joined. 09:36:45 -!- nfd9001 has quit (Read error: Connection reset by peer). 09:38:14 -!- nfd9001 has joined. 09:38:19 -!- tromp has joined. 09:57:55 -!- danieljabailey has joined. 10:09:58 -!- ais523 has joined. 10:13:00 @tell b_jonas No, the man pages describe the C wrappers. See https://github.com/torvalds/linux/blob/master/mm/mmap.c#L1624 10:13:00 Consider it noted. 10:13:06 @tell b_jonas However, it seems like only the "legacy" mmap call uses the struct wrapper, and the more modern mmap_pgoff (the one that takes page offset and is behind mmap2) is defined via SYSCALL_DEFINE6, so should in fact be callable: https://github.com/torvalds/linux/blob/master/mm/mmap.c#L1616 10:13:07 Consider it noted. 10:13:16 @tell b_jonas I know you can pass 6 arguments via the in 0x80 interface, I don't know why the old_mmap call packs them in a struct. Maybe the interface was slightly different in olden times. 10:13:16 Consider it noted. 10:15:54 -!- AnotherTest has joined. 10:43:47 I vaguely remember that an old, old syscall interface took fewer arguments than that 10:55:37 naturally; x86 simply had fewer registers to spare 10:59:36 -!- dingwat has quit (Ping timeout: 252 seconds). 11:01:01 -!- dingwat has joined. 11:34:48 Well, or so I thought. They're using all 7 of them now, even ebp, which I expected to be left out. 11:49:17 oh wow, why did I never see ELVM before? https://github.com/shinh/elvm 11:49:21 somehow I am not surprised at the author 11:49:51 (it's a C compiler modified to support a range of esolangs as backends, e.g. it can compile to BF, INTERCAL or Whitespace) 11:51:01 also, sizeof(char) == sizeof(int) == sizeof(void*), and CHAR_BIT varies but is usually 24 :-D 11:55:11 ais523: did you see the reference that I added to https://esolangs.org/wiki/Talk:Interfrac ? (I was almost giddy when I finally found it. It's actually a different source than I originally had for ILP in NP.) 11:55:36 (And I still don't know where that was.) 11:55:38 no, but I've seen it now 12:07:12 -!- mich181189_ has joined. 12:09:05 -!- S_Gautam has joined. 12:14:34 -!- Cale has quit (*.net *.split). 12:14:34 -!- mich181189 has quit (*.net *.split). 12:14:37 -!- mich181189_ has changed nick to mich181189. 12:17:34 -!- HackEso has quit (Ping timeout: 255 seconds). 12:17:41 -!- HackEso has joined. 12:20:48 -!- Cale has joined. 12:27:31 -!- wob_jonas has joined. 12:28:05 fizzie: was that old_mmap syscall even used on x86_32? 12:28:46 I'll try to look this up later 12:29:39 wati 12:29:45 there's a note about mmap in http://man7.org/linux/man-pages/man2/syscalls.2.html 12:30:53 fizzie: sorry, you're right. that note tells that because the original mmap is a very old syscall, it used to be called with a parameter block on x86_32, despite that six arguments can be passed in syscalls in x86_32 now 12:32:26 fizzie: ok, so you can call the mmap2 system call, or the ipc system call in the shmget mode, to get a memory mapping. 12:32:39 -!- Lord_of_Life_ has joined. 12:33:20 -!- Lord_of_Life has quit (Ping timeout: 244 seconds). 12:35:03 -!- Lord_of_Life_ has changed nick to Lord_of_Life. 12:45:44 -!- danieljabailey has quit (Ping timeout: 272 seconds). 13:11:17 ais523: yes, you're right, apparently there is a historical artifact there in the original mmap syscall. 14:03:45 shachaf: ftr, you're an evil person ;-) (I relented and bought Baba is You and I've already sunk 11 hours into it) 14:05:21 int-e: how many levels does that have? I hope they improved level design since that demo 14:06:24 more than a hundred 14:07:00 and at least one level is impossible (probably not really but I have no clue how it's supposed to work) 14:29:00 int-e: I see 14:33:49 suppose you're writing an esolang which does I/O as individual bits; should bits within a byte be big- or little-endian? 14:34:04 unlike bytes within a word, for which there are several good reasons to be little-endian, I can't see a reason to break the symmetry here 14:34:50 I guess I'd prefer big endian for human readability: 00100000 for a space 14:35:53 I guess big endian is slightly easier for input, little endian slightly easier for output? At least when doing the standard multiplication/division based base conversions. 14:36:01 I'm wondering whether one particular endianness might be easier to produce from within esolang code 14:36:20 hmm, yes, you save a temporary in both cases, don't you? 14:36:48 although not really, because you need a loop counter anyway, and you can use the same temporary for the loop counter and for remembering which bit you've reached 14:36:51 ais523: yeah, that's the sort of thing I have to decide for specifying (and implementing) a standard library for consumer society, although it's not necessarily base 2, I can use larger bases (3 or 4 or 5 or 8 or 16), and not only for IO, but for arithmetic too 14:38:13 so far I think I'll be using the endianness where the code emits the higher order bits first 14:38:14 also you can shift the bits into the number backwards, if you have 256/128 as a constant or wrapping storage 14:38:18 in BF it's often easier to read the top bit of a number than the bottom bit… 14:38:21 or, hmm, now I'm not sure; the top bit (for some fixed bitwidth) is easier to read in a non-wrappinig impl, but you can read the bottom bit in a wrapping impl by multiplying by 128 and checking to see whether you have 0 14:38:32 -!- ais523 has quit (Quit: sorry for my connection). 14:38:44 -!- ais523 has joined. 14:46:40 I think you can read the lowest bit in brainfuck too. 14:48:10 well, BF is transformation-on-memory-complete, the question is as to how easy the various bit-reading codes are 14:48:45 this problem comes up in The Waterfall Model too, I haven't decided whether it's easier to read high bits or low bits first 14:49:03 this should read the low bit: >[-]+>[-]>[-]<<< [- >[->>+<<]>[-<+>]>[-<+>]<<<] 14:49:07 (you either repeatedly halve, or else compare against something that's repeatedly halving) 14:49:26 clears the three fields to the right, then puts the parity to the field two to the right while zeroing the current cell 14:49:41 you could also copy the value if you don't want to destroy it 14:49:53 ais523: in a typical language I'd do the equivalent of acc = 0; for (i = 0; i < 8; i++) { acc = 2*acc + get_bit(); } 14:50:09 well, 128 in a wrapping impl can be obtained via --[>-<--]>- 14:50:32 you can change the >-< to a nondestructive add to get a nondestructive multiply-by-128 14:50:32 ais523: how do you read the seventh bit? 14:50:43 that's got to be shorter, but you'd then have to double the number to read the next bit 14:50:53 rather than acc = 0; bit = 1; for (i = 0; i < 8; i++) { if (get_bit()) { acc += bit }; bit *= 2; } 14:51:17 (this is assuming something without builtin bit shift (or exponentiation)) 14:51:55 acc = 0; for (i = 1; i != 256; i*=2) { if (get_bit()) acc += i; } 14:52:02 ... I misplaced that semicolon in "};". 14:52:15 I think that's less natural than your first example, but it's way shorter than the second 14:52:32 if I can compare wit 256 easily... sure. 14:52:44 well, in wrapping BF it's very easy, comparing with 256 is what ] does :-) 14:53:09 . o O ( let's take a 16 bit variant ) 14:53:15 ;) 14:53:32 then the same code reads a 16-bit character and you don't have to change it at all :-) 14:53:48 Also input may be less important than output? Or not? It really depends on what you want to do... 14:54:18 ...and the difference between big endian and little will always be relatively insignificant, I think. 14:55:20 what got me thinking about this was "suppose you're making an IR to target esolangs, what does I/O look like?" 14:55:40 unary is an option and has several advantages, but also a clear disadvantage 14:58:31 -!- arseniiv has left ("gone too far"). 14:58:43 -!- arseniiv has joined. 15:01:10 I think the optimum is probably unary for text output (likely with 1 = NUL, 2 = SOH, etc., and 0 = EOF); and binary for binary output 15:01:24 (in either case the language itself would just output 0s and 1s, just the interpretation of them would be different) 15:03:41 ais523: I'm definitely not going to use unary. I'm going to use radixes between 2 and 16 inclusive. 15:04:31 wob_jonas: well, we're designing different languages, so your usecase may well be different from mine 15:04:47 I guess this goes back to the whole "what is a number?" question 15:05:10 sure 15:05:20 and in esolangs, at least, the answers seems fairly clear for nonnegative integers: it's a count of something, typically data or loop iterations 15:05:58 part of the reason why I want a radix higher than 2 for some options is to make the code more compact, so that if I want to put an integer literal in the source code, I don't have to enter 32 bits, but instead just 8 hexits 15:05:58 so "do this 4 times" is a property inherent in the number 4, it's what defines it, really (because it lets you impose 4ness onto arbitrary structures) 15:06:07 and "output a 1 bit 4 times" is how you output the numebr 4 in unary 15:06:26 wob_jonas: isn't that just syntax, though? you could have the lexer expand your high-radix number into unary 15:06:29 (+)*12345 15:07:38 ais523: the syntax itself doesn't know about numbers. only the standard library knows about them, and the standard library interface is such that I can implement the arithmetic library in pure Consumer Society. in fact that's how I want to implement it first, just to prove that it works, and then I add an optimized implementation into the interpret 15:07:38 er. 15:08:07 the library can't add arbitrary syntax to the language 15:08:14 OK, and you don't want a preprocessor 15:08:51 yes, or at least, I have a specific syntax in mind, and want to make that work 15:09:36 the reference implementation would then store the numbers as binary internally 15:09:44 but that isn't visible in the interface 15:10:05 well, IMO a good Underload interpreter should store numbers in binary 15:10:12 internally 15:10:15 but the syntax doesn't work like that at all 15:10:43 why not? if you want to handle large numbers in underload, you can implement a binary representation in underload just fine 15:11:12 in this case I want to handle 32-bit numbers because I decided I want to implement the SGB random generator, and that uses 32-bit division 15:11:43 and then I'll implement a maze generator that calls that random number generator 15:12:03 wob_jonas: because the binary representation is very inconvenient for working with 15:12:10 you wouldn't be able to multiply with just *, for example 15:12:14 so some numbers will be greater than 2**30, but I won't repeat anything as many times 15:12:44 make the interpreter use bignums internally 15:12:51 ais523: yes, I'll have to implement the multiplication and division myself. I've implemented binary arithmetic a fwe times already, so I know what I'm getting myself into 15:13:01 all esolang interpreters should do that unless the esolang inherently has a word size cap (which IMO is bad esolang design) 15:13:11 ais523: for underload, yes, I'd use bignums. for Consumer society, that's not so easy 15:13:56 from my point of view, the best way to write esolangs is normally for the program to handle numbers in unary (simplest), and the interpreter to optimize that, unless the esolang is timing-dependent in some way and thus can't be optimized 15:14:42 it's not that 32 bits is an inherent limit. I could implement 128 bits instead if I wanted to, for just slightly larger code, but if I do 32 bits, that makes it clear enough that I could do larger if I wanted while keeping the code clean. 15:18:22 it'd be hard to imagine an esolang where 32 bits /is/ an inherent limit (so, of course, I'm trying) 15:26:10 ais523: I don't think it would be hard. x86_32 already has built-in 32-bit integers, and you can encourage that even more if you don't expose a carry flag and don't expose high multiplication. 15:27:04 yeah, and don't expose double shift and don't expose unsigned division either. it goes a long way to make longer arithmetic inconvenient, but still totally realistic and characteristic of real cpus. 15:27:24 sure, that means it's for non-esoteric languages, but I don't see why an esoteric language couldn't do the same 15:27:44 intercal already has 16 bits as an inherent limit, and I can imagine a 32-bit variant. 15:56:27 the 16 is arbitrary though 16:08:03 [[Livefish]] N https://esolangs.org/w/index.php?oldid=60558 * Areallycoolusername * (+1681) Created page with "[[Livefish]] is an [[esoteric programming language]] made by [[User: Areallycoolusername|Areallycoolusername]]. It's the opposite of [[Deadfish]] in that it has a way to input..." 16:10:55 [[Joke language list]] https://esolangs.org/w/index.php?diff=60559&oldid=60547 * Areallycoolusername * (+71) /* General languages */ 16:17:12 -!- wob_jonas has quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client). 16:18:30 Livefish would be /way/ more interesting if i was input, and o was some other operation 16:18:39 that said, it would still likely be uninteresting 16:19:11 [[Livefish]] https://esolangs.org/w/index.php?diff=60560&oldid=60558 * Areallycoolusername * (+131) 16:19:18 you can write practically useful TC input-only languages, though (e.g. context-free grammars); they provide observable output in the form of halt/nonhalt 16:19:32 [[Livefish]] https://esolangs.org/w/index.php?diff=60561&oldid=60560 * Areallycoolusername * (-31) 16:20:41 [[Livefish]] https://esolangs.org/w/index.php?diff=60562&oldid=60561 * Areallycoolusername * (+6) 16:22:08 [[Livefish]] https://esolangs.org/w/index.php?diff=60563&oldid=60562 * Areallycoolusername * (+10) 16:22:42 [[Livefish]] https://esolangs.org/w/index.php?diff=60564&oldid=60563 * Areallycoolusername * (-17) /* Categories */ 16:51:54 int-e: Which level is impossible? 16:53:00 Level 12 in the forest... skull house. I don't want any spoilers though. 16:54:05 Of course. 17:05:55 [[User:Areallycoolusername]] https://esolangs.org/w/index.php?diff=60565&oldid=59883 * Areallycoolusername * (+249) 17:07:07 [[User:Areallycoolusername]] https://esolangs.org/w/index.php?diff=60566&oldid=60565 * Areallycoolusername * (+34) 17:07:19 [[User:Areallycoolusername]] https://esolangs.org/w/index.php?diff=60567&oldid=60566 * Areallycoolusername * (+2) 17:48:45 -!- S_Gautam has quit (Quit: Connection closed for inactivity). 17:51:21 -!- danieljabailey has joined. 17:55:49 -!- adu has joined. 18:16:01 Huh. I somehow thought when you call int 0x80 in a 64-bit binary, you go through the compatibility layer where the syscall numbers are the x86-32 ones, and you pass in 32-bit ebx/ecx/edx/etc registers. In actual fact, it looks like when I call int 0x80 it's interpreted using the 64-bit syscall numbers and register order. Or at least that's how strace is printing them. 18:16:21 Maybe strace is just confused by the whole concept. Because the call doesn't actually do anything, and it prints "?" as the return value too. 18:19:38 Right, I think that's just strace. Because when I try to run the regular "syscall"-based version with int 0x80, strace prints write(1, "Hello world!\n", 13) = ? but the process just exits. (The 64-bit syscall write number 1 is exit on the i386 side.) 18:20:17 -!- b_jonas has joined. 18:20:31 I guess I just won't use strace; just wanted to use it to validate the args. Still getting a -1 (EPERM) out of the purported mmap call. 18:22:56 Oh, looks like it might actually care about fd needing to be -1 when MAP_ANONYMOUS is set. The man page was ambivalent (stating it should be ignored), so I left it at 0 as that was easier. 18:24:36 Or not. I'm getting EBADF when I try to set it to -1. 18:26:09 -!- FreeFull has joined. 18:48:57 -!- danieljabailey has quit (Read error: Connection reset by peer). 18:50:57 "you can write practically useful TC input-only languages, though (e.g. context-free grammars)" => huh what? no context free grammar is Turing-complete 18:51:05 ais523: ^ 18:51:37 I meant context-sensitive grammars 18:51:48 and said the wrong thing out of habit because CFGs are common and CSGs are rare 18:52:20 fizzie: try to call write first, that has the same syscall number in all versions, right? 18:52:46 b_jonas: No, that's what confusing me right before you joined. 18:53:10 b_jonas: The 32-bit write (1) is actually the 64-bit exit, so strace printed "write(...) = ?" + "program exited". 18:53:33 fizzie: what I don't know is, when you call a syscall with int 80, what registers or register halves is the syscall allowed to clobber 18:53:44 for the proper x86_64 syscall interface, I do know the answer 18:53:59 but not for the int 80 18:54:00 Er, I mean, the 64-bit write (1) is the 32-bit exit, is what I needed to say. 18:54:09 wait what? 18:54:12 even that's changed? 18:54:13 wow 18:54:18 Single-stepping with gdb confirms that it exits immediately on the "int 0x80" where eax/rax is 1, so it's being treated in the 32-bit manner, even though strace prints it it as write. 18:55:25 fizzie: even without strace or gdb, you could get a few bits result out if you make the program (1) call an illegal instruction, (2) cause a segmentation fault by writing to the null page, (3) livelock with an infinite loop 18:55:28 Yes, the syscall_64.tbl list starts at 0 with "read, write, open, close, ..." while the syscall_32.tbl starts from 1 (well, 0 is restart_syscall, that's special) with "exit, fork, ...". 18:56:04 -!- adu has quit (Quit: adu). 18:56:26 -!- adu has joined. 18:56:34 the 32-bit one starts with exit, fork, read, write, open, close, waitpid, creat, link, unlink, execve, chdir, time, mknod, chmod, lchown, break 18:56:51 -!- adu has quit (Client Quit). 18:56:51 hmm 18:57:11 -!- adu has joined. 18:57:38 -!- adu has quit (Client Quit). 18:57:39 that could get ugly the other way, if you try to call write, but actually call fork 18:58:05 -!- adu has joined. 18:58:16 In any case, I'm a bit unsure about this EBADF. I think it's likely using the x86-32 argument registers, because when I change the fifth register (edi) from 0 to -1, the return value goes from -1 (EPERM) to -9 (EBADF). 18:58:17 and what does the sysenter interface do? is that the same as the int80 interface? 18:58:25 -!- adu has quit (Client Quit). 18:58:28 ...uh, actually, scratch all that. It's just that I can't count. 18:58:47 Turns out 0x20 | 0x40 *isn't* actually 0x40, but 0x60 instead. 18:58:48 -!- adu has joined. 18:58:57 Who knew. 18:59:11 -!- adu has quit (Client Quit). 18:59:22 Well, then it all makes sense, it doesn't have 0x20 (MAP_ANONYMOUS) set so it's either trying to mmap stdin (EPERM) or -1 (EBADF). 18:59:44 -!- adu has joined. 18:59:53 yeah, it ought to use the x86_32 register conventions if you use int80 18:59:58 -!- adu has quit (Client Quit). 19:00:27 so the syscall number goes in eax, and the arguments to ebx, ecx, edx, esi, edi, ebp 19:00:44 EPERM seems like an interesting error for mmapping stdin 19:01:13 it should be EACCES according to the docs 19:01:31 oh, but EACCES is "Permission denied" 19:01:37 (EPERM is "Operation not permitted") 19:02:04 EPERM The prot argument asks for PROT_EXEC but the mapped area belongs to a file on a filesystem that was mounted no-exec. 19:02:10 It kind of might be an instance of that sort of thing. 19:02:21 I was trying to map it rwx just because there's no reason not to. 19:02:32 oh, I see 19:02:41 I normally avoid +x in maps 19:02:52 ais523: yeah, what fizzie says, plus /dev/pts is mounted noexec 19:02:53 besides, mapping /anything/ rwx is a huge w^x violation 19:02:58 I thought I might want to run some code in there, though right now it doesn't. 19:03:16 Anyway, with the flags fixed (MAP_PRIVATE | MAP_ANONYMOUS | MAP_32BIT), it's now returning a pointer in the low 32 bits, so that should be fine: http://ix.io/1Ee2 19:03:24 ais523: like I said yesterday, rwx used to be normal, because for a pretty long time, x86 didn't have a way to mark pages (as opposed to segments) readable but not executable 19:04:03 b_jonas: clearly you should just make your mutable variables write-only, then 19:04:29 (this is… possibly viable given the right sort of language?) 19:04:40 ais523: old x86 didn't allow marking a page executable but not readable either 19:05:01 now I'm wondering what operations x86 allows on write-only memory, can you do RMW instructions if they don't have visible side effects? I'm guessing no 19:05:48 -!- sebbu3 has joined. 19:06:10 the whole non-executable page thing came about only because of security people trying to reduce effects of bugs 19:06:49 wtf was these loud noise 19:09:26 -!- sebbu has quit (Ping timeout: 250 seconds). 19:12:30 Aw. Works locally, crashes on HackEso. That might be a little annoying to debug. 19:12:46 fizzie: ouch 19:12:54 fizzie: how do you even compile it on HackEso? 19:13:03 oh wait 19:13:10 `` echo 'const char main[] = "%0000%HELOP[P]P_4~PY4yPZ4eP^,b,@̀PYSX5Hell1ADSX5o wo1AHSX5rld!1ALSX4@4J1AP4@4GPZ$AP[QX4DPYRX$D̀ß";' | gcc -x c - -o /tmp/hello4 && /tmp/hello4 19:13:11 you're compiling a x86_64 program, sorry 19:13:11 ​/hackenv/bin/`: line 5: 64 Segmentation fault /tmp/hello4 19:13:14 that you can compile 19:13:41 try cheating by making the program not of that format 19:13:59 That command line prints "Hello world!" on both my home machine and this work computer. 19:14:25 Yeah, will have to look into it a bit later, need to go grocery shopping. 19:14:36 But I know the format in general works. 19:15:02 `` echo 'const char main[] = "%0000%HELOPPPPPPT]5Hell1E XP5o wo1E$XP5rld!1E(XP4@4J1E,4@4GPZ$AP_^^^^T^\17\5XX\303";' | gcc -x c - -o /tmp/hello4 && /tmp/hello4 19:15:04 Hello world! 19:16:43 The int 0x80 version also works on the machine HackEso is running on, so it's something about the UML sandbox. Which isn't *that* surprising: UML in general does weird things about memory. 19:16:55 Actually, it's a separate Linux kernel. 19:17:05 Maybe it's compiled without the 32-bit emulation in the first place. 19:18:01 hmm 19:18:20 it sure does 19:22:52 I do have that working version that doesn't use any syscalls at all, I just suspect if I finish converting it to be printable in a naive way, it's going to end up being longer than comfortably fits on an IRC line. 19:24:12 ``` set -e; >tmp/a.c echo $'#include\n''int main(void) { printf("hello ifrzMgePz7Lg,\n"); }'; gcc -g -Wall -O -fdiagnostics-color=never -o tmp/a.out tmp/a.c; tmp/a.out 19:24:14 hello ifrzMgePz7Lg, 19:24:46 does it have to fit in an irc line? you can just use multiple irc lines 19:24:59 I guess it doesn't, really, just would be more elegant if it did. 19:25:10 If the word "elegant" can really be attached to that. 19:25:22 fizzie: it's really the -fdiagnostics-color=never why I don't want to insist on putting all the compilation stuff in one irc line 19:25:51 it's just a ridiculously long compilation option, and the gcc defaults and libc defaults are somewhat bad for historical reasons, 19:26:20 so you can end up needing stuff like -std=gnu++-17 and #define _GNU_SOURCE and twenty includes just to do nothing 19:26:35 and I don't want to omit those just to golf the program 19:27:16 The non-syscall code walks up the stack to reach the ELF auxiliary vector, picks up the AT_PHDR pointer to locate the program header, scans that to find the PT_DYNAMIC section, looks up the DT_DEBUG entry used for communicating between the dynamic linker and a debugger, uses the link_map chain there to enumerate all loaded shared objects, scans through their symbol tables to find "exit" and "puts", and 19:27:22 finally uses those to do the job. 19:27:37 fizzie: ok, wait a moment 19:27:51 I think I read something relevant yesterday, let me look it up 19:28:02 hmm wait 19:28:06 that was for x86_32 code 19:28:21 so that can't work 19:29:06 but still, even in x86_64, there must be a function with a syscall instruction mapped somewhere, that the kernel and libc together use for signal handler magic 19:29:12 -!- tromp has quit (Remote host closed the connection). 19:29:41 Yes, I could definitely do it much easier if I were willing to make it work on one specific libc. 19:29:55 (Or scan through memory to find suitable bytes.) 19:30:12 (Well, maybe that wouldn't be so much easier than the enumerate-symbols approach.) 19:30:56 There's also an easy-to-find entry to locate the vDSO page, which could be used to make a version that reliably works on one specific kernel. 19:31:54 On x86-32 systems, the vDSO actually has a function just for this, __kernel_vsyscall, which is there so that userspace apps can just call that instead of having to do the work of deciding whether sysenter is supported. 19:32:34 On x86-64, that's not there, the page contains just __vdso_clock_gettime, __vdso_getcpu, __vdso_gettimeofday and __vsdo_time. 19:33:04 Some of those do have syscall instructions that could be jumped to, but again that would make the solution brittle if the vDSO contents change. 19:33:06 -!- sebbu3 has changed nick to sebbu. 19:39:01 fizzie: but doesn't it have to work that way on any libc? I mean 19:39:14 fizzie: what does the kernel put on the stack when it calls a signal handler? 19:39:29 fizzie: I vaguely remember Web of Lies scanning the vDSO to find a syscall instruction 19:39:32 doesn't it put a return address to a routine that calls the magic system call that tells the kernel that the signal handler has finished? 19:39:37 wasn't there something like that? 19:39:39 and then jumping to it via IP teleportation over ptrace 19:39:50 maybe I'm confused 19:39:52 (it seemed saner than trying to alter the executable's memory image to do a system call) 19:39:53 I'll have to test that 19:43:21 I think there's a specific system call (sigreturn?) somewhere in user-space code that signal handlers return to, which then informs the kernel that the signal handling is done. But I'm not sure how that helps for this. 19:43:40 Unless there's an easier way to find that code than there is to find the puts/exit functions. 19:44:21 syscall/signal interaction is interesting 19:44:37 the kernel frequently, either virtually or actually, rewinds the IP a couple of bytes to send it over the same syscall again 19:44:44 that's how restartable syscalls are restarted, for example 19:45:00 it wouldn't surprise me if sigreturn is used as a replacement syscall for nonrestartable signals in much the same way 19:45:26 (fwiw, this mechanism makes it highly likely that syscalls use only caller-saves registers, as it'd be hard to get the parameters correct otherwise) 19:46:51 ais523: is that really what the kernel does? I always thought it was the libc that handled all the restarting, by intercepting all the sigaction calls to know which signals it has to restart after, and restarting on a -EITNR in the C functions that call the system call 19:47:07 b_jonas: no, it happens in the kernel, you can see this using strace 19:47:27 there are a few really out-there signal numbers (not in the normal sequence) reserved for this purpose 19:47:31 and I think the sigreturn had some other reason to exist, not the syscall restarting 19:47:34 I can't remember whether they're negative or really large 19:48:16 but I didn't pay much attention to the whole system call restarting thing, because why would you want that? the whole point of signal handlers is that they must be able to wake up your program, and you can only do that if the system call isn't restarted 19:48:36 in blocking high level functions like fread, sure, there you restart 19:49:02 b_jonas: well, if you've set the signal to SIG_IGN, you presumably don't want the signal to interrupt the system call 19:49:10 sometimes that's implemented as restarting it 19:49:13 but otherwise, when a signal interrupts a syscall, it will be the blocking syscall that is the center of your event loop, like poll or something 19:49:33 I do understand that the restarting must be handled for compatibility with existing programs of course 19:50:17 ais523: no! if you set it to SIG_IGN, then the system call isn't interrupted at all, from the user process's point of view. the kernel doesn't have to restart anything, or even interrupt the system call, because it doesn't have to invoke a handler 19:50:39 I vaguely remember that the kernel actually /does/ interrupt the system call while it checks to see if there's a handler 19:51:35 and SIG_IGN has some special semantics for the kernel anyway, it's not just like calling an empty handler: SIG_IGN is inherited through an execve, SIG_IGN on SIGCLD makes the kernel wait all your children when they die. 19:52:33 well, what actually matters is the SA_RESTART flag on the signal handler, which can be set independently per-handler (although it defaults to off unless you're using SIG_IGN, IIRC) 19:52:36 that is why you have to be very careful with SIG_IGN: if a child accidentally inherits it, you can get really hard to debug bugs 19:53:03 there was a particularly nasty bug in linux distros where some process set sigprocmask and children inherited it, the same could happen with signaction SIG_IGN 19:54:02 well, there are some programs that do this sort of thing intentionally 19:54:04 nohup comes to mind 19:54:18 ais523: yeah, I guess what you're saying makes sense, because libc can't easily tell which signal interrupted the syscall 19:57:50 oh, I know why! 19:58:55 ais523: the kernel must put something on the stack because on signal return the stack pointer must be modified. on x86_32 that's only if a sigaltstack is active, but on x86_64 always, because there's a redzone 19:59:27 oh right, you can't clobber the redzone 19:59:27 you can't just have the signal handler return like a normal C function, the stack pointer would be wrong 19:59:58 what even is the purpose of that thing, anyway? 20:00:58 is it just to save a few assignments to SP? or is there some better optimization you can do with it? 20:01:23 ais523: uh, some optimization thing, but I'm not sure what right now 20:03:12 -!- tromp has joined. 20:03:21 ais523: I think part of that is that the one-byte displacement you use in x86 addressing modes is a signed int8 20:03:48 but I think there's something other than that, possibly connected to instructions like push/pop 20:04:32 the redzone is 128 bytes, isn't it? that would make a lot of sense if it's the signed-int8 displcement that's relevant 20:07:04 ais523: something close to that, yes 20:11:20 ais523: it also allows you to load a value from the stack with pop but still keep the copy on the stack 20:12:10 well, the copy isn't on the stack any more, it's in the redzone, but I know what you mean 20:12:13 I'm not saying this comes up often, but the redzone doesn't have much of a price either 20:13:06 if the kernel calls a signal handler, those 128 bytes don't cost much even when you aren't using them 20:13:08 b_jonas: there's also the bit that tail functions don't have to set up their own stack frame if they need fewer than 120 or so bytes. 20:14:44 int-e: that could be true even if the redzone was over *rsp, not under, if the calling convention just said that the 120 bytes over the return addess are callee-clobbered 20:15:58 int-e: basically you have a choice of a constant offset of where the rsp points, and it only matters for when the stack is accessed with small displacements or call/ret/push/pop or similar which use a fixed displacement 20:16:07 b_jonas: then you'd pay 120 bytes of stack space for every level of function calls even if no stack frame is allocated at all 20:16:17 (just for the return address) 20:16:35 hmm 20:16:39 oh, because it would intersect the previous ret address? 20:16:45 yeah, sorry, you're right 20:16:49 that wouldn't work 20:17:08 Err, yes, I think what I said is correct. I'm confusing myself. 20:18:14 int-e: yes, what you say is correct. because the call/ret instructions access right above *rsp, you want space below that that can be used even if you did a dense series of calls and pushed above *rsp 20:19:16 so the stuff you access with call/ret/push/pop and kin are above the stack pointer, and some of the thing you access only with displacements, not with those instructions, can be above 20:19:20 some of them can be below 20:19:37 or perhaps 20:21:19 well, there definitely has to be a boundary somewhere on the stack so that above that is generally preserved by the callee, below that can be clobbered 20:22:53 and because of how call/ret/push/pop works, it makes sense to put that boundary near *rsp 20:23:28 which is why there's a scratch area below [rsp] 20:25:51 well, I don't really claim I understand this 20:26:02 figuring out good general-purpose calling conventions is a very hard problem 20:26:08 good thing we already have one to use 20:28:33 it's probably only good on x86 20:28:39 well sure 20:28:43 and any goodness it has is relative to the general insanity of x86 20:28:49 this is cpu-dependent 20:28:57 and this is on x86_64 in particular 20:45:15 ah, the linux manpage http://man7.org/linux/man-pages/man2/sigreturn.2.html gives some info 20:46:20 ah yes! 20:46:48 besides setting the stack pointer, it resets the saved sigprocmask. I knew there was something I missed 20:54:42 hmm 20:55:29 that won't help, because you need at least either a system call or a symbol lookup to find that function that the signal handler stack frame calls, 20:55:54 and if can you do a system call or symbol lookup then you no longer need that 20:56:32 no wait 20:56:32 wait 20:57:07 it's a bit non-portable because it technically depends on the kernel version, but you can find the address from just the auxiliary vector I think 20:58:47 oh 20:58:50 it might be even better 20:58:53 I'll have to test this 20:59:13 hmm no 20:59:15 darn 20:59:29 I dunno 21:02:29 nope 21:02:41 you need a symbol lookup into libc I think 21:02:46 so it won't help 21:16:22 [[User:Hakerh400]] https://esolangs.org/w/index.php?diff=60568&oldid=60554 * Hakerh400 * (-188) /* Programming languages we created */ 21:16:34 [[Truth-machine]] https://esolangs.org/w/index.php?diff=60569&oldid=60486 * Illuminatu * (+177) /* Implementations */ 21:18:43 [[Aeolbonn]] https://esolangs.org/w/index.php?diff=60570&oldid=20079 * Illuminatu * (+97) /* Examples */ 21:28:31 -!- arseniiv_ has joined. 21:31:44 -!- ais523 has quit (Quit: quit). 21:32:05 -!- arseniiv has quit (Ping timeout: 252 seconds). 21:33:23 smh. arduino is doing some terrible thing where code inside comments gets preprocessor-expanded and then has compiler-level syntax errors 21:33:32 I should once again ditch it and write basic AVR C 21:33:40 but it's so convenient to throw things together 21:33:43 when it isn't fucking you over 21:38:29 -!- arseniiv_ has changed nick to arseniiv. 21:38:44 kmc: ouch 21:40:24 -!- arseniiv_ has joined. 21:41:12 -!- arseniiv__ has joined. 21:44:11 -!- arseniiv has quit (Ping timeout: 246 seconds). 21:44:40 -!- arseniiv_ has quit (Ping timeout: 246 seconds). 21:50:29 -!- arseniiv__ has quit (Ping timeout: 246 seconds). 22:00:59 -!- Phantom_Hoover has joined. 22:01:05 -!- Phantom_Hoover has quit (Changing host). 22:01:05 -!- Phantom_Hoover has joined. 22:06:14 apparently used items are now described with the euphemism "pre-owned" rather than plain "used" or "second-hand" 22:06:57 (I'm shopping on ebay.com) 22:08:42 that's been the case for a looong time 22:08:44 at least for cars 22:09:10 kmc: I haven't been shopping online for long yet 22:09:19 only for like two years so far 22:09:27 ah 22:09:30 I'm somewhat conventional and find it hard to get used to 22:09:34 I bought my car online 22:09:36 also I'm definitely not buying cars 22:09:40 which is weird because no test drive 22:09:45 but they had a 14 day return policy 22:09:52 and as it turns out I love that car 22:09:59 kmc: um, just because it's online you could have a test drive 22:10:11 it was used 22:10:14 even then 22:10:18 how do you figure 22:10:55 you search in the catalog of cars for sale, you contact the owner that you're interested, 22:11:13 you agree with them at a time and place, and possibly pay an advance, and try the car before agreeing to take it, 22:11:33 because especially for a used car there are a lot of things you may want to check directly on the car, that you can't see on photos or descriptions 22:11:36 as in hidden errors 22:11:50 this need not include a test drive, but it can 22:12:12 depends on stuff like whether the car still has permission to run and insurance 22:12:36 and whether it needs things fixed in a garage immediately after buying 22:14:21 I'm buying cheap new items online, but see used ones in the listing when I search 22:14:48 obviously I have to check that field that says "brand new" 22:14:56 or "new (with tags)" 22:15:51 that's not how buying cars online works 22:15:55 it could have been thousands of miles away 22:16:00 and, the seller does an inspection 22:16:11 and you handle your own insurance and registration 22:16:21 but yeah I was a little scared of getting ripped 22:16:22 off 22:16:24 but it was fine 22:16:30 "thousands of miles" probably no, but a few hundred kilometers certainly 22:16:34 ok 22:16:43 sorry, I live in Europe, it's smaller 22:16:46 you're once again pulling stuff out of your ass regarding things you've never done 22:17:03 I wasn't buying on craigslist 22:17:18 I went through a middleman that provides various services 22:17:23 they also handled the registration for me 22:17:24 ok 22:17:29 which was convenient, although it took a long time 22:17:39 so a used cars sales company 22:17:40 makes sense 22:18:38 sorry, I wasn't thinking of that, because my family and some co-workers bought and sold some cars and motorbikes recently, and they all bought or sold them directly to the previous or next owner, not through a used car professional 22:19:27 but yes, agents handling sales of cars do exist here too 22:22:25 eh it's ok 22:22:29 i got pissed off unnecessarily 22:22:32 it happens a lot :/ 22:22:39 sorry 22:23:11 -!- Essadon has joined. 22:23:13 I'm not saying that either method is better 22:23:22 you can't trust individual people, but you also can't trust agents 22:23:49 s/people/owners/ 22:24:27 so in python, you can call list or tuple with an existing list as an argument to make a shallow copy, right? 22:24:40 let me test to make sure it's really shallow 22:25:17 yeah, shallow 22:25:18 good 22:26:52 you can call it with any iterable 22:26:54 and yeah, it's shallow 22:30:31 `` python3 <<<'a=[[4],[5]];b=list(a);a[0][0]=6;a[1]=[7];print(a,b)' # yes 22:30:32 ​[[6], [7]] [[6], [5]] 22:30:44 bzzzzonk 22:31:15 `quote 22:31:16 843) i think the problem is you're trying to interpret finnish as logic. 22:31:19 `quote 22:31:20 1075) i guess the fact i won't eat bovine tongue is just tranferred cod trauma. 22:31:23 `quote 22:31:24 465) Maybe if you try diplomacy. Pointy steel diplomacy 22:41:04 -!- AnotherTest has quit (Ping timeout: 272 seconds). 22:48:16 -!- Phantom_Hoover has quit (Remote host closed the connection). 23:01:50 -!- Phantom_Hoover has joined. 23:03:17 -!- tromp has quit (Remote host closed the connection). 23:26:07 Someone read the story I wrote of GURPS game I played, and their idea is that Ziv should just bite off the shapeshifter's face. 23:28:08 But I would think that would be difficult for a few reasons. 23:38:27 -!- tromp has joined. 23:42:52 -!- tromp has quit (Ping timeout: 250 seconds). 23:58:15 -!- oerjan has joined.