channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev&y=18&m=9&d=19
12:00:05 <geist> that's what windows classically did, and i think most 32bit systems that wanted to support a lot of ram eventually end up doing
12:00:38 <heat> can't we just admit that when the attacker gets code running in kernel space you're already screwed?
12:00:46 <zid> it isn't about 'code running'
12:00:52 <zid> it's about gadgets you leave laying around etc
12:00:52 <heat> what is it about?
12:01:00 <geist> you can at least either segment the BAMM into multiple chunks and spread them around the kernel
12:01:14 <geist> i think a lot of meltdown sploits on linux at least involve probing the BAMM
12:01:15 <zid> if all they get is a read gadget, not having the entire universe visible at a fixed address is *incredibly* important
12:01:18 <yasar> klange, your OS has GUI, which is probably more exciting
12:01:32 <yasar> klange, is that gnome?
12:01:42 <zid> it immediately defeats aslr and gives up all encryption keys, without any execution at all
12:01:45 <geist> so anyway, ASLRing your BAMM helps a bit
12:01:47 <klange> no, my GUI is all my own
12:01:57 <heat> well yeah
12:02:03 <heat> it's possible to aslr it
12:02:16 <geist> within limits, since it greatly helps to use at least 2MB pages to map it
12:02:18 <zid> if it's fixed, anyway, there's still relatively few bits you can randomize something that large to in 48 bit address space unless you're also taking hits on putting it at weird non-2M addresses
12:02:20 <geist> preferably 1GB pages
12:02:54 <geist> yah that's why i was thinking if you never use more than one page at a time, you can at least segment the BAMM into randomized chunks
12:03:06 <zid> I considered just having a identity_page
12:03:19 <geist> trouble there is if you ever look up a pag eyou can't assume that subsequent pages are back to back
12:03:20 <zid> for virt_to_phys or whatever
12:03:24 <yasar> klange, how long did your OS take you from start to that level?
12:03:42 <klange> about five years
12:04:10 <heat> geist: how does zircon do it?
12:04:45 <zid> I probably still have bugs in my page tables from not wiping the pointer in the bottom 8 bytes somewhere in my alloctor :p
12:05:36 <yasar> klange, do you have a public repo of it?
12:06:08 <heat> Oh wow, they added python bindings to ACPICA in BITS
12:06:19 <heat> I didn't know I needed that, but now I totally need that
12:06:23 <bcos_> Back in the early 1990s (when Linus first started using BAMM) things were very different - for one random example, there was no "ecrypt/don't encypt" flag in every physical address
12:06:25 <mischief> .theo
12:06:26 <glenda> Right now, you are not talking facts.
12:06:43 <klange> yasar: old OS is at https://github.com/klange/toaruos
12:06:43 <bslsk05> klange/toaruos - Hobby kernel + userspace, built mostly from scratch. Composited GUI, dynamically linked ELF binaries, networking, Python applications, and more. (273 forks/2333 watchers)
12:06:53 <heat> .theo
12:06:53 <glenda> So what is learned here?
12:07:01 <klange> yasar: my current project is at https://github.com/klange/toaru-nih
12:07:01 <bslsk05> klange/toaru-nih - A completely-from-scratch hobby operating system: bootloader, kernel, drivers, C library, and userspace including a composited graphical UI, dynamic linker, syntax-highlighting text editor, network stack, etc. (7 forks/59 watchers)
12:07:09 <zid> klange is in a loop
12:07:13 <zid> quick, hit him with a wrench
12:07:37 <klange> I am functioning nominally, no percussive maintenance is necessary at this time.
12:07:46 <zid> can I do it anyway?
12:08:51 <heat> .theo
12:08:51 <glenda> You sir, are just wastewater.
12:13:08 <zid> Okay here's my new plan, instrument the linux kernel and record the pci-e transactions done for a teapot demo
12:13:14 <zid> and then just spam them onto the bus
12:13:24 <zid> now my OS has a full 3D graphics stack
12:13:48 <klange> brilliant, 3D graphics by replay attack :)
12:13:55 <heat> sortie kinda did that for a 'tiny' radeon driver for his gpu
12:14:02 <klange> tbf that's how a lot of early modesetting drivers were written
12:14:03 <heat> it works but it's very broken
12:14:13 <zid> it's very broken!? *shocked*
12:14:22 <heat> yeah, shocking
12:14:58 <yasar> klange, it looks awesome. If I could boot and put something in screen I would feel like ultimate hacker :)
12:15:41 <klange> you are in a channel with dozens of people who work on operating system projects
12:15:52 <zid> https://github.com/zid/boros/blob/master/boot/boot.asm There, now you're done yasar :P
12:15:53 <bslsk05> github.com: boros/boot.asm at master · zid/boros · GitHub
12:16:45 <heat> >someone posts a link to a project
12:16:54 <zid> delete line 3, then replace line 17 with mov word [edi], 'AA' or something
12:16:56 <heat> welp, time to check it out
12:17:16 <zid> >jan 2016, if you have questions, I can't answer them :P
12:17:17 <klange> I'm trying to collect bootable images of various hobby OSes
12:17:36 <heat> zid: you're missing locks on pci_read*
12:17:37 <bcos_> ..to train your new AI OS generator
12:17:45 <zid> heat: I am not missing any locks.
12:17:51 <heat> yes you are
12:17:55 <zid> I most definitely am not
12:18:04 <heat> You most definitely are
12:18:14 <zid> are you making stupid assumptions for fun or just to look silly?
12:18:47 <heat> it's not a stupid assumption
12:19:16 <zid> Tell me, what would the lock prevent?
12:19:35 <heat> there's a race condition right there, 2 pci accesses could race for the CONFIG_ADDRESS
12:19:49 <zid> why would there be 2 pci acesses?
12:20:09 <heat> because there can be more than 2 drivers accessing stuff, maybe?
12:20:16 <zid> see, there go your silly assumptions.
12:20:25 <zid> 'maybe', and infact, no
12:20:31 <heat> why not?
12:20:46 <zid> because there isn't
12:20:49 <zid> reality is not configured that way
12:20:58 <heat> there isn't yet
12:21:07 <zid> so what you're saying is, you agree, there is no possible race
12:21:28 <heat> it's possible, it's just not getting triggered yet because you don't have 2 drivers racing for it
12:21:40 <zid> So it would be possible, if it were possible, which it isn't, got it
12:22:17 <zid> if you want to crash my OS you don't even need to /edit the code to make it crash/ you can just put a <2M region into the e820
12:22:49 <heat> that's not an excuse to be lazy IMO
12:22:57 <zid> It's nothing to do with lazy.
12:23:09 <zid> How do you verify locking works if you don't have to readers or writers?
12:23:13 <zid> s/to/two
12:24:20 <heat> locks or the pci code?
12:24:49 <zid> what
12:25:08 <heat> do you mean the lock implementation or the pci code that has a race condition?
12:46:14 <oo_miguel> ls
12:46:16 <oo_miguel> ah sry
12:56:37 <klange> i was going to post some ls output in response, but I'm 10 minutes late, so, nvm
01:01:31 <oo_miguel> haha
01:07:05 <oo_miguel> hmm it seems newlib does not flush printf on exit..
01:08:52 <zid> did you exit cleanly
01:10:00 <oo_miguel> i "call main, push %eax, call exit"
01:10:05 <oo_miguel> aaaah
01:10:43 <oo_miguel> no nothing...
01:10:58 <oo_miguel> what do you mean by cleanly?
01:11:24 <zid> not clling exit
01:11:33 <zid> that is just 'kill my process please'
01:11:35 <klange> calling exit is exiting cleanly
01:11:40 <zid> not by C's standards
01:11:42 <klange> _exit is "please kill me"
01:11:58 <oo_miguel> yeah i call exit which in turns calls my kernels _exit I thin
01:12:02 <oo_miguel> think
01:12:15 <oo_miguel> but this should be called AFTER streams where flushed etc right?
01:12:15 <klange> but it doesn't matter because you need to setup the plumbing to get newlib to do that
01:12:40 <zid> oh apparently that's a lie
01:12:46 <zid> maybe I was just dealing with a buggy libc
01:12:54 <zid> you were right klange
01:13:06 <oo_miguel> registerin atexit functions works fine for example
01:13:07 <zid> abort doesn't need to clean up
01:13:20 <oo_miguel> but printf is not flushed for instance
01:13:25 <zid> but I've used a libc where exit did abort or _exit and got the wrong behavior in my head
01:13:29 <zid> printf does not need to be flushed
01:13:32 <zid> do you mean stdout
01:15:23 <oo_miguel> isn't that identical?
01:15:29 <zid> printf is a function
01:15:33 <zid> stdout is the output stream
01:15:34 <oo_miguel> printf("foo"); fprintf(stdout,"foo");
01:15:49 <oo_miguel> aaah
01:16:00 <oo_miguel> might printf also buffer internally?
01:16:08 <zid> no, stdout may be though
01:16:11 <geist> printf no, FILE * yes
01:16:33 <geist> fflush(stdout); usually puts an end to that
01:16:34 <zid> Your 'terminal' may buffer, and FILE * is set to buffered by default afaik
01:16:45 <oo_miguel> I have printf("no nextline"); and I do not see any output in my toykernel with newlib
01:16:55 <oo_miguel> but I see it on my regular debian distro
01:17:01 <geist> yes. usually it keys off of \n or fflush(stdout);
01:17:23 <geist> or if using c++, cout << std::endl; I believe
01:18:22 <clever> ive also found that if stdout is a tty, it will be unbuffered
01:18:30 <geist> yah
01:18:34 <zid> clever: I think the terms used are 'interactive mode'
01:18:34 <clever> but if you redirect stdout to a file or pipe it to a program, it will be buffered
01:18:44 <zid> for the tty buffering stuff
01:18:53 <oo_miguel> clever: aaah that explains everything
01:19:06 <clever> and if you forget to implement that difference in your kernel
01:19:28 <oo_miguel> I did not implement that differecne
01:19:32 <oo_miguel> out of laziness
01:19:46 <oo_miguel> just return the same thing for everything
01:20:09 <clever> newlib may not realize the tty is interactive then
01:20:57 <geist> or not even check
01:21:07 <geist> it's somewhat simpler
01:21:13 <oo_miguel> clever: I suppose newlib checks this via stat and I always tell it is a S_IFCHR
01:21:37 <zid> or rather, it treats it as interactive, so it is buffered
01:21:49 <clever> The isatty() function tests whether fd is an open file descriptor referring to a terminal.
01:21:54 <clever> this function exists on linux
01:22:06 <clever> isatty() returns 1 if fd is an open file descriptor referring to a terminal; otherwise 0 is returned, and errno is set to indicate the error.
01:22:08 <oo_miguel> ah I always return 1 here
01:23:28 <clever> oo_miguel: does it behave differently if you always return 0 instead?
01:29:16 <oo_miguel> hmm sorry I guess the value is not returned properly. I have to check this, thanks
01:32:08 <klange> A good beginner hack for isatty is to return (fd < 3)
01:39:04 <oo_miguel> ah i am returning 1 (I got confused coz it was shown incorrectly in gdb).. but still printf is NOT flushed
01:39:30 <oo_miguel> files I open via fopen get flushed and closed
01:40:07 <oo_miguel> but I can live with that
01:40:08 <klange> i'm pretty sure newlib is line buffering by default and that the "interactive" case is not something that applies here
01:40:25 <klange> does fflush do what it's supposed to?
01:40:35 <oo_miguel> I can change the buffering in case I need
01:40:39 <oo_miguel> yes fflush works fine
01:40:59 <klange> I think because of the way exit is implemented in newlib, you have to make sure the streams are flushed yourself
01:41:40 <oo_miguel> klange: allright thanks. I just thought it is my fault coz it works differently on my real os :)
01:41:52 <oo_miguel> but I also do not use newlib there
01:42:02 <klange> I'm just going on what I remember from old ToaruOS
01:42:13 <klange> which I think still has this bug of not flushing streams on exit
01:42:16 <zid> if he just has a bug in his terminal code and it loses messages from exited processes
01:42:24 <zid> if? or
01:53:42 <yasar> I just completed barebones tutorial
01:53:53 <yasar> it was fun :)
01:54:01 <geist> grats
01:54:35 <klange> i need to implement a more... correct stdio. I don't even have output buffering at the moment. I have read buffering, but I'm not sure how the writes are supposed to interact with the buffer alongside reading... gotta do some reading myself :)
01:55:43 <zid> klange: C actually requires an fseek between fwrite and fread, but posix does not, for extra fun
01:55:48 <zid> I think I mentioned that a couple of days ago though
01:56:23 <klange> Yeah, fseek is supposed to reset all the buffering so it doesn't really matter.
01:56:29 <yasar> I want to get current time to display after barebones tutorial. What should I be googleing?
01:56:51 <clever> yasar: https://wiki.osdev.org/RTC
01:56:52 <bslsk05> wiki.osdev.org: RTC - OSDev Wiki
01:57:18 <clever> yasar: https://wiki.osdev.org/CMOS#Getting_Current_Date_and_Time_from_RTC
01:57:20 <bslsk05> wiki.osdev.org: CMOS - OSDev Wiki
01:57:24 <zid> bonus fun: windows stores the time dst ajusted in the cmos
01:57:25 <zid> because it's insane
01:57:44 <Mutabah> fuu-uun
01:57:47 <clever> zid: in the past (win98 era), windows stored the fact that DST was adjusted in the registery
01:57:56 <zid> right, it knew it did it so it was fine for windows
01:58:03 <zid> but it's insane for everybody else
01:58:06 <clever> zid: my school had software to undo any unauthorized changes to the machine
01:58:07 <clever> including the fact that the DST change was applied
01:58:14 <zid> hah nice
01:58:18 <clever> so when spring comes by, it rolls the clock forwards an hour, every time you boot the machine
01:58:29 <yasar> Hmm, I remember the time being off when I switched from linux/windows couple of years ago
01:58:33 <yasar> might be the reason
01:58:36 <zid> indeed it was
01:58:47 <zid> you need to set conf.d/localtime to windows compat or whatever your distro uses
01:58:52 <clever> yasar: linus keeps the CMOS clock in UTC by default
01:58:56 <clever> linux*
01:59:07 <clever> windows keeps it in local, and moves it forward/back an hour when DST flips
01:59:22 <clever> linux wouldnt have that problem my school caused, because the clock never changes when DST flips
01:59:25 <zid> ah it's /etc/conf.d/hwclock:CLOCK="local" for me
01:59:49 <klange> you can set windows to use UTC
01:59:54 <zid> windows doesn't believe anything other than windows or anything more than 1 user could ever exist
02:00:01 <klange> which I think is the saner approach then telling Linux to emulate the stupid thing Windows does
02:00:06 <klange> than*
02:00:12 <zid> no idea how to change it on xp or whatever
02:00:12 <clever> zid: ive read about the horrors of switch-user on windows
02:00:29 <clever> zid: there is a crap-ton of global vars relating to the currently active destkop (and rdp multi-deskop fun)
02:00:35 <clever> zid: and it has to update them on every context switch
02:01:06 <clever> thats what happens when you put your GUI in the kernel :P
02:01:07 <zid> yea doesn't look like youcan control it from xp
02:01:28 <geist> either one works, i usually just fiddle it to follow what windows does
02:01:39 <zid> I set it to local if windows is installed
02:01:56 <geist> yah. honestly that isn't any more insane. i think it makes a certain sense
02:02:00 <zid> It is just Known that windows will be an asshole, fixing windows is harder than reconfiguring linux
02:02:07 <clever> zid: also, at one point, windows put font rendering into the kernel, to cheat at some benchmarks
02:02:16 <klange> of course not having DST is the real sane choice
02:02:18 <clever> now you have truetype font exploits that gain execute in ring0!
02:02:19 <clever> yay
02:02:28 <zid> geist: Makes no sense to me, it implies every user on the machine is in the same timezone and that my timezone isn't codified by politics which might change
02:02:32 <Mutabah> I dunno about calling that cheating...
02:02:39 <klange> clever: that's how we hacked the original xbox
02:02:59 <zid> I love the xbox security talk
02:03:05 <zid> I should watch it again.. again, it has been a year or two
02:03:08 <geist> zid: okey dokey
02:03:26 <clever> zid: link?, i remember something different involving a custom bytecode interpreter in the boot rom
02:03:27 <zid> on linux my timezone is a file which is pulled from my distro and gets updates
02:03:47 <zid> clever: That's the dashboard bug, means you don't have to use a buggy game
02:03:58 <zid> the hw exploits to overwrite the boot rom etc are the best part yes
02:03:59 <klange> my laptop moves around because I travel; the displayed timezone is irrelevant to the hardware clock
02:04:31 <zid> klange: And you moving the laptop then changing timezone shouldn't, imo, fuck with the monotonic time in the cmos
02:04:35 <clever> klange: xfce lets me set the timezone on the clock widget, so i have 4 clock widgets in different zones
02:04:41 <clever> klange: so i can track what time it is for coworkers
02:04:41 <klange> zid: exactly
02:04:59 <zid> I don't even think the cmos should be writeable from the OS
02:05:10 <zid> it should be write-protected by the bios when it hands off to 7c00
02:05:15 <klange> well someone's gotta make sure the clock doesn't drift
02:05:29 <zid> ntp correction factors
02:05:40 <zid> it can just have a userspace cummulative delta
02:05:55 <zid> if your clock is wrong in the bios screen itself.. you're in precisely the place you can change it
02:06:06 <clever> zid: you need to know both the offset, and the rate of drift
02:06:08 <zid> and it may have cuased mobo makers to not ship such shitty clocks
02:06:10 <clever> zid: and the bios doesnt let you set the clock to within 1ms
02:06:32 <clever> have fun even getting it accurate to the second :P
02:06:45 <zid> clever: That's.. completely trivial? lol
02:07:18 <zid> in-bios time doesn't need to be accurate to more than like, an hour, and in the OS ntp can add the milliseconds back on
02:07:18 <clever> zid: if its off by half a second, it will appear to be in sync 50% of the time and out by 1 second 50% of the time, if you cant see the ms
02:07:29 <clever> zid: windows doesnt run ntp at bootup
02:07:41 <zid> it's my fault windows is dumb? I said the bios clock shouldn't be writeable
02:07:45 <clever> my linux machine drifted by 20mins once, and the windows guest in virtualbox inherited that offset
02:07:45 <zid> that means we'd be in a different universe
02:07:51 <zid> where they probably would have enabled it
02:08:06 <clever> fixing it in windows didnt help, because the offset returned when rebooting the guest
02:08:20 <zid> I just synced mine, it was perfect :(
02:08:21 <clever> took a few days to notice it was the host to blame
02:08:36 <clever> ntpd was failing hard due to syscall policies it set on itself
02:09:00 <zid> weird, mount put the warning about switching defaults to stronger samba encryption in dmesg
02:09:25 <zid> not stdout/stderr
02:10:14 <zid> I use a lot of vms so I just run ntp in them because I like to suspend them, and then my git repos get all sorts of fucked up dates in them otherwise
02:10:32 <zid> pulled frm master, edited it 4 days in the past in the VM, pushed it out
04:34:39 <johnjay> zid: i've been wondering about that. if you freeze a linux machine and then restart it does that cause problems?
04:36:46 <zid> no, as far as the computer is concerned nothing happened
04:37:01 <zid> it.. can't have done any wrong math or anything, it wasn't running :P
04:37:17 <johnjay> oh your problem is the machines are networked together
04:37:36 <johnjay> or am i misreading?
04:37:42 <zid> I have no problem
04:37:43 <johnjay> you said your get repos get fucked up
04:37:46 <johnjay> *git
04:38:07 <zid> You need to switch your clock from "counting how long I have been running" to "look at this clock on the wall"
04:38:14 <zid> because obviously the former is unreliable
04:38:27 <zid> if time is going forwards but the clock isn't
04:39:25 <johnjay> the google search i did suggested using nptdate?
04:39:34 <johnjay> can you background it or just make it run regularly?
04:39:44 <zid> ntp is how you "look at this clock on the wall" yes
04:40:20 <johnjay> ah ok. it seemed like you'd have to run it every second
04:40:28 <johnjay> so that whenever you resume it it would update
04:40:49 <zid> you just run it after you resume..
04:40:53 <zid> then youcan go back to counting seconds
04:41:23 <zid> Imagine I had a chinese guy sat at a desk with a metronome, and I told him it was noon, and every time the metronome ticked, he should add a second to his count
04:41:34 <zid> tick, 1 second past 12, tick, 2 seconds past 12, etc
04:41:35 <geist> hmm, re a conversaion like 10 hours ago: you can definitely download and just run zircon
04:41:38 <johnjay> ok but that requires typing
04:41:44 <johnjay> not a good solution
04:41:50 <zid> it's a perfectly fine solution
04:42:06 <zid> I am aware of when the date is wrong, because I am the one who 2 seconds ago caused it to be wrong
04:42:38 <johnjay> geist: i'd like to try that!
05:24:34 <graphitemaster> osdev logs still not working
05:26:15 <klange> The "Today's log" link continues to not work - I don't know if it's been set up to pull from globbot yet.
05:26:35 <klange> But the globbot logs, which are linked in the "Channel logs" link at the top continue to work https://freenode.logbot.info/osdev/20180919
05:26:39 <bslsk05> freenode.logbot.info: #osdev
05:27:19 <graphitemaster> I miss the stats page and random quotes
05:27:25 <klange> Those should be working.
05:27:27 <graphitemaster> that's what I liked the most from the old logs
05:27:35 <klange> http://bespin.org/~qz/irc/2018-09-September.html
05:27:35 <bslsk05> bespin.org: #osdev @ FreeNode stats by clog
05:27:50 <zid> ircstats woo
05:27:52 <klange> there is a quote from me from the 15th
05:27:56 <klange> so it's definitely working
05:28:30 <burzos> I want to implement malloc/realloc/free. To track the allocated/unallocated chunks I want to use a balanced tree. How do I do allocations for my metadata, since I obviously don't have an allocator?
05:29:03 <Mutabah> Stick the metadata on the allocations themselves? (just before the block is a common trick)
05:29:26 <Mutabah> Or, have a specialised allocator just for the metadata (which will all be equal-sized)
05:29:28 <zid> burzos: shitty allocator in the bootloader, map everything everywhere, etc
05:30:35 <zid> burzos_: shitty allocator in the bootloader, map everything everywhere, etc
05:31:04 <burzos_> zid: Talking about my usermode allocator.
05:31:15 <zid> Then you do have an allocator
05:31:18 <zid> it's the kernel one
05:32:10 <klange> burzos_: that's part of the challenge of writing a heap allocator is figuring out how to link your data allocations to their metadata and where to store it all :)
05:32:30 <zid> zidlist is clearly the solution here
05:32:44 <burzos_> Hm, so just grab some pages to store the metadata for my usermode allocator, then don't worry about freeing them
05:32:57 <zid> sounds like you're inside out?
05:33:39 <zid> not *for* your usermode allocator, *from* your kernel. Just mmap a bit extra and use it as metadata area
05:34:42 <burzos_> Ok, then I can even unmap the metadata if the process no longer uses the maps for data.
05:36:47 <zid> like I said, you do have an allocator
05:37:42 <burzos_> You are correct, I do have an allocator.
05:40:27 <graphitemaster> actually, writing a generic heap allocator is relatively a solved problem until you begin talking about threads
05:40:35 <graphitemaster> the best algorithm is still basically a form of dlmalloc in the end
05:41:00 <graphitemaster> all advancements in generic heap allocators have been about reducing lock contention when multiple threads are hitting it
05:41:11 <graphitemaster> that's when you start talking about thread caching and other things
05:41:19 <graphitemaster> you can probably ignore that for now in your os though
05:41:26 <burzos_> Lots of locality issues I think
05:41:29 <graphitemaster> just roll a basic dlmalloc-lite you're not going to improve it
05:42:10 <klange> My heap allocator was written for a uni project, it was part of a little competition
05:42:13 <graphitemaster> obviously non-generic allocators you can do better
05:42:23 <graphitemaster> but that's not really a good discussion
05:44:56 <mobile_c_> do registers have a default universal size?
05:45:19 <mobile_c_> or is the registers size dependant on its purpose and architecture
05:45:22 <zid> People need to start using allocators that suit the task, imo
05:45:53 <zid> I've looked at a lot of 80s code that used buckets of common objects and just wiped them and handed them back out
05:46:01 <zid> that'd be even more of a performance win now than it was then
05:46:05 <bcos_> mobile_c_: dependant on purpose and architecture
05:46:15 <Mutabah> mobile_c_: Registers are sized differently on each architecture (and quite often based on purpose)
05:46:28 <mobile_c_> ok
05:47:18 <mobile_c_> in what section might i be able to find information about the register sizes
05:47:34 <Mutabah> Section of what?
05:47:35 <mobile_c_> in the ISA manuals
05:47:47 <Mutabah> You're going to have to be more specific
05:48:09 <mobile_c_> for example, ARM architecture
05:48:30 <Mutabah> Usually, that sort of information would be very early in the documentation
05:48:37 <mobile_c_> or specifically ARM V7 profile A
05:48:38 <bcos_> Which ARM architecture?
05:48:43 <bcos_> Ah
05:48:53 <Mutabah> (as register size is a very important piece of information)
05:49:53 <mobile_c_> rip it isnt as easy as just searching for "register size" in the ARM pdf x.x
05:50:19 <mobile_c_> (as it returns no results)
05:50:26 <Mutabah> To save you a bit of bother - All general purpose registers on ARMv7 are 32 bits long
05:51:07 <mobile_c_> ok
05:51:31 <mobile_c_> would that mean those only work on a 32 bit architecure
05:51:36 <mobile_c_> architecture*
05:52:03 <Mutabah> Well, ARMv7 is usually called a 32-bit architecture
05:52:48 <mobile_c_> so if im writing an emulator for that is it possible to get it to compile for 64 bit architectures
05:53:09 <bcos_> ?
05:53:36 <burzos_> Your emulator could work on a 64bit host.
05:53:43 <bcos_> "I'm cooking a cake. Come someone explain how to cook and describe what a cake is?"
05:53:47 <mobile_c_> for example, size diferences between C types as per architecture specifics
05:54:03 <mobile_c_> eg int is 4 bit on 32 but 8 bit on 64
05:54:10 <Mutabah> C has fixed-size interger types for when you care about the size
05:54:33 <Mutabah> (In fact, many coding standards require use of those over short/int/long
05:55:26 <mobile_c_> and im assumign there is no int4_t ? (as the minimum seems to be int8_t
05:55:37 <mobile_c_> assuming*
05:55:41 <bcos_> 32-bits = 4 bytes = uint32_t
05:57:12 <mobile_c_> so if a int is 8 bits does it mean it is typedef int64_t on x86 and int32_t on x32?
05:57:48 <klange> i think you are confusing bits and bytes
05:58:10 <mobile_c_> if a int is 8 bytes on x86 and 4 bytes on x32*
05:58:11 <bcos_> I think you don't know C, don't know ARM, don't know programming, and don't belong here
05:58:34 <bcos_> (and especially shouldn't be writing an ARM emulator in C)
05:58:56 <Mutabah> well, not yet. You need to get an understanding of the language first
05:59:10 <zid> bcos_: Which is precisely why I ignored him the first time he spoke in ##asm :P
05:59:23 <zid> too many people give help vampires / mental patients / etc their time
05:59:47 <zid> it's bad for both sides
06:00:03 <zid> you're essentially tricking them into staying, they're not going to get anywhere no matter how long they stay
06:00:06 <Mutabah> zid: Eh, sometimes it's fun
06:00:08 <zid> and you're going to lose 100 hours of your life
06:02:41 <bcos_> mobile_c_: Mostly; you should focus on (e.g.) a C tutorial to learn C (if that's what you're going to use); then learn assembly language for ARM (if that's what you want to emulate)
06:02:55 <klange> I recommend learning how to computer. It's a very useful life skill.
06:03:13 <mobile_c_> also, how would i call functions that require specific types, if i have int32_t type registers, for example, something that requires a char * type but i give it the address of a int32_t
06:03:33 <Lowl3v3l> mobile_c_: learn fucking C.
06:03:41 <klys> so many self-defeating questions
06:03:45 <klange> That's like C 101 there.
06:03:53 <Lowl3v3l> mobile_c_: and then, in 3-5 years go back to what you want to do now.
06:04:18 <klange> Or maybe 201 after we eliminated the freshman-level C courses because the department wanted to move to Java for introductory courses...
06:05:04 <zid> woo java, learn how to optimize for the jvm which has nothing to do with how to optimize for computers
06:05:18 <klys> mobile_c, obviously th4e correct way to do things isn't the wrong way, so it doesn't make a very good example to do things wrongly.
06:07:18 <zid> What's that addage, dress for the job you want or whatever?
06:07:23 <zid> That applies equally to being good at a thing.
06:07:30 <zid> Act how a pro would act.
06:08:23 <klys> perhaps did you havea question about endianness? arm mach8ines are little-endian afaik.
06:09:41 <klys> or if it's a question about pointers to registers, there are no pointers to registers; only pointers to memory.
06:10:21 <klange> ARM is configurable endian, though usually LE.
06:10:35 <klange> But if you're feeling kinky...
06:10:44 <zid> klys: just fyi you're probably the 8th person I've seen tell him something extremely basic like that
06:10:44 <klange> It can go both ways.
06:10:45 <Mutabah> (Because little LE is the only one that makes sense :D)
06:11:21 <klys> yeah zid
06:11:22 <zid> LE has a benefit, BE has a benefit, but they are not the same benefit
06:11:24 <mobile_c_> wait how tf would i call a function that uses a stack, as i cant replace the hosts stack with the virtual stack implimentation then just call the funtion
06:11:45 <mobile_c_> as that would likely mess up the entire application
06:11:54 <zid> LE has type truncation/extension that works automatically, BE is easier to read :P
06:12:07 <klange> wow, just... the level of naïvety in that question is...
06:12:07 <mobile_c_> fk
06:12:25 <zid> he doesn't know what any of the words mean, he's basically a markov chain
06:12:33 <klys> if you're reading the arm cpu manual, there would be no such thing. please less self-defeating questions.
06:12:34 <zid> that's why his questions sounds so fucked up
06:13:00 <mobile_c_> ik but C itself uses a stack
06:13:24 <klys> all the stacks get piled on top of the other stacks.
06:13:33 <Lowl3v3l> would you do your duty, klange-hime?^^
06:13:48 <zid> kurangie
06:13:52 <klange> Unfortunately, being hilariously ignorant is not against the rules.
06:13:58 <zid> there are rules?
06:13:59 <Lowl3v3l> damned
06:14:01 <mobile_c_> is it even possible to replace a stack in C?
06:14:04 <zid> I thought moderation was to benefit the channel
06:14:08 <zid> not to punish people
06:14:17 <Lowl3v3l> mobile_c_: stop. Just stop.
06:14:30 <zid> I'd say it's clear which side his presence puts him on of that line
06:14:35 <Lowl3v3l> mobile_c_: tell me the the first world war started
06:14:41 <zid> also ty english for being fucked up enough to let me write that sentence in that form
06:14:52 <klys> mobile_c, nope. you use assembly to switch stacks. and you don't need to anyway, as switching stacks is a very specialized edge case.
06:15:24 <zid> Lowl3v3l: Someone asked me why one of the world wars started because he was 13 and just finished his module on history or whatever and wanted to show off to me, so I blew him the fuck up that was funny
06:15:45 <klange> mobile_c_: Your questions, which seem to be more personal ramblings and stream of thought, demonstrate a profound lack of knowledge about both C and computer architecture, as well as an inability to accept answers you have been given.
06:16:40 <Lowl3v3l> zid: actually i wanted him to stumble upon the ill formed question ( the word "year" is missing), if he's not a markov chain he should be able to tell this is not a valid question and ask or infer "year" is implied and answer correctly.
06:16:47 <klange> But beyond that, they aren't really on-topic for this channel.
06:17:02 <zid> Lowl3v3l: I have him ignored, I just wanted to tell you my not that interesting story :P
06:17:07 <mobile_c_> if the number of arguments a function can take is greater then the available registers that are used to store arguments, those arguments will be stored on a stack, correct?
06:17:15 <zid> He was adamant the super low-level surface only 'reasons' were correct, it was funn
06:17:44 <klys> mobile_c_ by default all arguments are stored on the stackl and none of them are stored in registers.
06:17:48 <klange> Normally we would make exceptions when regular members with long histories talk about off-topic things, but you are new and thus I'm going to suggest you go somewhere else.
06:18:10 <zid> he'll just go back to ##asm and then bcos_ can go back to babying him there dw
06:18:14 <zid> he won't miss anything here
06:18:21 <klange> Freenode is a big place dedicated to computer-related subjects, so we can afford to be very specific about what we consider on-topic.
06:18:34 <mobile_c_> klys: ok
06:18:35 <Mutabah> klys: Let klange deal with this, they're not responding to direct questions/comments, so are either a bot or a troll/ignorant
06:18:57 <Mutabah> ... and as soon as I say that, there's a direct response.
06:19:14 <zid> Mutabah: His engine had to process enough text to be able to format a response
06:19:15 <klys> mutabah, what would you like to talk about
06:19:59 <zid> which one of you is buying me a dedicated dev machine for my birthday btw
06:20:13 <klange> what's your address and when is your birthday?
06:20:26 <klys> happy birthday zid
06:20:29 <zid> 25th of october, dropbox
06:20:46 <klange> Unfortunately, Dropbox doesn't accept physical uploads.
06:20:51 <zid> no, an actual dropbox
06:20:55 <zid> like an actual segue
06:21:13 <klys> those exist in britain, i gather
06:21:19 <klange> The company is Segway, so that's not actually ambiguous.
06:21:22 <zid> anywhere that has spies has them
06:21:23 <klange> (in text at least)
06:21:30 <zid> or banks
06:22:15 <klange> Those are safety deposit boxes.
06:22:50 <zid> https://www.google.com/search?ei=H-uhW-zeGYrGgAapl4a4Bg&q=%22drop+box%22+bank+of+america&oq=%22drop+box%22+bank+of+america
06:22:58 <zid> 400k results
06:23:09 <bslsk05> www.google.com: "drop box" bank of america - Google Search
06:23:11 <klange> That's a different thing, though.
06:23:29 <zid> The word means what it means, that it's attached to a bank means it is for dropping payments and shit
06:23:30 <klange> Bank drop boxes are places to send checks and money to be processed by the bank.
06:23:39 <zid> see how you prefixed that with bank, that's my entire point
06:23:43 <klange> You can't send a computer to a drop box.
06:23:49 <zid> Sure you can, if the hole is computer shaped
06:23:52 <zid> mobos are thin anyway
06:24:08 <klys> lewd
06:24:16 <klange> If you're not giving me your address, I'm not getting you a development machine, end of story.
06:25:08 <zid> I'm cautious of bombs, I'm a bit of an asshole to some people
06:27:14 <zid> If I were to seriously consider this, I wonder what'd make a good machine
06:27:21 <zid> probably something with pci + pci-e slots, more than one core
06:27:27 <zid> intel gma I guess?
06:27:52 <klys> I picked up a machine like that at a thrift sore last month for 5.00
06:27:56 <zid> wow nice
06:28:17 <klys> dell optiplex 330
06:28:20 <zid> I live out in the sticks, not much chance to get anything decent at the charity shop
06:28:41 <zid> it's just old-lady-knick-knacks going in a perpetual circle between the old ladies
06:28:49 <Mutabah> Any local universities/colleges?
06:28:50 <zid> one dies, the other 99 buy all her stuff from the charity shop, repeat
06:29:12 <klange> It's more of a spiral than a circle
06:29:18 <zid> I guess
06:29:21 <Mutabah> Institutions of any decent size tend to toss out half-decent kit, and may allow you to buy them for cheap
06:29:26 <klange> As the old ladies die, younger ladies get older and replace them.
06:29:45 <zid> I think I still owe the closest college some money :P
06:30:01 <klange> Probably best to stay away, then.
06:30:16 <zid> they never asked for it back so whatever
06:30:32 <klys> well that actually depends, they discard record after five years or so
06:30:39 <klys> records*
06:30:55 <zid> they can keep em for however long they want
06:31:09 <klange> Well, it depends. If it was in the form of unpaid loans it never expires but it's also not owed back to the school, just to the loan servicer.
06:31:10 <klys> coo
06:31:34 <zid> nah they had some agreement or whatever where they paid for public transit passes for the first term and third term of a three term year
06:31:42 <zid> but I got them to switch the second and third terms
06:31:46 <zid> but didn't do the third term
06:32:18 <klys> yeah so you're in a situation to be dropping out
06:32:22 <zid> so they paid twice and I paid 0 times, but he system is precisely set up so that they pay for 1, or 2/3rds, not 100% of 2
06:32:43 <zid> I wonder if it even showed up on their books that I did that
06:33:15 <zid> I don't think they give too much of a shit, apparently one student didn't even pay for the course because they just forgot to ask him, lecturer told him to just keep his moth sure
06:33:21 <zid> also his mouth, not sure why he had any moths
06:55:46 <klys> geist: "Chrome OS Revamp Delivers a New Look and Linux App Support"
07:18:50 <mobile_c_> is a NORMAL stack (eg linked list/array) different from a CPU's stack (eg stack pointer and how ever it impliments its stack)
07:27:58 <_mjg> these are vastly different things
07:28:15 <_mjg> if you mean 'stack' from your algorithm course, then the cpu stack is nothing like it
07:28:29 <_mjg> well not nothing, but it is not useful to think about it in the above terms
07:28:44 <_mjg> did you have your operating system ourse?
07:29:14 <zid> he caught another one? wow
07:30:28 <geist> klys: mkay
07:34:00 <mobile_c_> i mean like a hardware stack
07:34:26 <mobile_c_> or whatever the correct term for it is
07:36:04 <Mutabah> Conceptually, they're both the same (they're LIFO structures) - but the CPU stack is just a single pointer that points (usually) to the last-pushed item on the stack
07:37:24 <mobile_c_> Mutabah: so would the hardware stack need to be implimented using an array and not a linked list?
07:37:45 <Mutabah> ... yes.
07:38:49 <Mutabah> It's worth learning assembly programming (even just a little bit of it) before starting on writing an emulator
07:39:20 <mobile_c_> Mutabah: im doing that as i go lol
07:40:08 <mobile_c_> Mutabah: as i want to make sure every instruction i add works the same as its architecture equivilant
07:40:30 <Mutabah> The manuals should include pseudocode of what each instruction does
07:40:40 <mobile_c_> i know
07:41:01 <Mutabah> Also, ARM doesn't explicitly use the "stack" (there is a 'SP' register, but that's convention only)
07:42:11 <mobile_c_> Mutabah: so the stack is implimented on ARM?
07:42:32 <mobile_c_> Mutabah: or is there just no stack whatsoever
07:42:51 <mobile_c_> regardless of the language being compiled to ARM
07:42:51 <Mutabah> The architecture has no concept of a stack
07:43:11 <mobile_c_> eg stackless C, stackless JAVA, ect
07:43:48 <Mutabah> The stack is just an ABI construct on ARM
07:43:48 <mobile_c_> or do the languages themselves have there own implimentation of a stack when nesisary
07:44:11 <Mutabah> Again... you should go elsewhere and learn some basic assembly programming first
07:46:10 <Ameisen> What's the advantage of a programming language with strong nullability - where you can define types that cannot be null?
07:46:22 <Ameisen> In the end, that just requires you to use Optional or something similar
07:46:25 <Ameisen> and I don't see what you've gained
07:46:53 <Mutabah> Well, when you _don't_ use an optional, you knwo that the pointer is never null
07:46:58 <burzos_> zid: So the usermode malloc/free impl. is, to a first order, really about reducing the number of syscalls.
07:46:59 <Mutabah> (and hence don't need to check)
07:47:19 <Mutabah> burzos_: Kinda... but also for finer-grained allocations
07:47:31 <Ameisen> You also use that if you use a NotNull wrapper or such
07:47:34 <mobile_c_> ok wtf, if ARM itself has NO concept of a stack then why tf doe all stack implimentations seem to just use STM and LDM
07:47:35 <Ameisen> or, in C++, a reference
07:47:41 <mobile_c_> do all*
07:47:50 <burzos_> Mutabah: Presumably my kernel mode impl. could do fine grained allocations as well.
07:47:57 <Mutabah> mobile_c_: Well, that's becasue the STM/LDM instructions can be used to implement a stack :)
07:48:30 <mobile_c_> how, it HAS no stack
07:48:36 <Mutabah> burzos_: It could, but that puts a lot of pressure on the kernel
07:49:31 <burzos_> What do you mean by kernel pressure and why is it bad?
07:49:49 <Mutabah> mobile_c_: The CPU doesn't have any hard-coded stack support, but it has instructions that can be used to implement the push/pop instructions from other architectures which do have ingrained stack support
07:50:10 <Mutabah> burzos_: well, it puts the complex and fiddly logic of variable-sized alloctions in the kernel
07:50:26 <mobile_c_> Mutabah: ffs
07:50:54 <burzos_> If I had a rock solid implementation, that would be less of an issue.
07:51:17 <burzos_> It doesn't seem too crazy to formalize the allocator.
07:51:46 <Mutabah> burzos_: The way nearly every OS works is that the kernel handles allocating on a page (4KB) granuality
07:52:10 <Mutabah> burzos_: Then a userspace allocator handles splitting those allocated pages into arbitary sizes
07:52:28 <mobile_c_> like does it have a stack or not (even IF it is not EXPLICITLY CALLED a stack or not)
07:52:41 <burzos_> But if my implementation is rock solid, and syscalls aren't expensive. I could just do it in the kernel.
07:52:59 <Mutabah> mobile_c_: Read the first couple of chapters of the ARM Architecture Reference Manual
07:53:35 <Mutabah> burzos_: You _could_... but now everyone has to use your in-kernel allocator, instead of their potentially faster custom allocator
07:55:01 <burzos_> Well, my in-kernel allocator will still do page size allocations if that's what you ask for.
07:55:04 <mobile_c_> Mutabah: would it be in A3
07:55:35 <burzos_> page size multiple*
07:55:54 <mobile_c_> (Application Level Memory Model)
07:57:11 <Mutabah> mobile_c_: probably not, there should be an overview
07:58:07 <Mutabah> The point I'm trying to make is: ARM (unlike x86) doesn't have a hard-coded "stack" in the CPU (there isn't a special "stack pointer" register). Instead there's a set of instructions that can load/store and update a register in the same operation
07:58:30 <Mutabah> This allows any register to be a stack pointer (although, one of them is the "stack pointer" by convention)
08:00:05 <mobile_c_> so a cpu stack is just a pointer to a specific memory region?
08:00:14 <Mutabah> Yes.
08:00:39 <mobile_c_> and what defines the start and end of that region
08:00:48 <Mutabah> It's just a pointer that moves up/down as things are pushed/popped
08:00:50 <Mutabah> Nothing
08:01:00 <Mutabah> Which is why stack overflows can be a problem
08:01:30 <Mutabah> (the "start" is pretty safe, you usualyl can't underflow without serious bugs)
08:01:40 <Mutabah> (but the "end" can be hit if you have excessive/infinite recursion)
08:02:03 <mobile_c_> for example: 0x7ffffffde000 0x7ffffffff000 0x21000 0x0 [stack] what defines 0x7ffffffde000 as the start and 0x7ffffffff000 as the end
08:02:27 <klys> geist, is this a chromeos release that you were working on?
08:02:36 <Mutabah> The OS decided "this is the area I'll reserve for the process's stack"
08:02:51 <mobile_c_> ok
08:03:06 <mobile_c_> and the cpu has no knowlege of this correct?
08:03:46 <Mutabah> yep, all it sees is an address that you use for load/store instructions
08:04:03 <mobile_c_> ok
08:05:33 <mobile_c_> so assuming the base memory as 200MB (as obvioudly it is IMPOSSIBLE to use the full 4GB available unless ur on a 64 or greater, bit archetecture with 4GB+ ram), how would one set up a stack region
08:05:44 <zid> burzos_: late af, but sorta but not really? syscalls are expensive sure but complicated list walks can dwarf it
08:06:06 <zid> a couple of cache misses are going to cost you that same syscall penalty
08:06:37 <Mutabah> mobile_c_: That's getting into really complex stuff that I don't have time to explain. Maybe you could find suitable information on the web about it?
08:06:38 <zid> (unless you're on skylake then you can just pretend a syscall ends the universe)
08:06:47 <mobile_c_> ;-; ok
08:06:50 <zid> Mutabah: if he could do that he wouldn't ask what a register was 10 times a day
08:08:12 <klys> mobile_c_, the ss register is a selector into the GDT or LDT, which points to the low boundary and length of your accessible region. http://wiki.osdev.org/Segmentation
08:08:13 <bslsk05> wiki.osdev.org: Segmentation - OSDev Wiki
08:08:29 <klys> ack, not on ARM iirc
08:08:32 <Mutabah> klys: ... That is not helping at all
08:08:50 <Mutabah> yep.
08:08:54 <klys> idk
08:09:12 <mobile_c_> Mutabah: so would this be somewhat accurate as a mental note? the stack is defined as a implimented specific region of memory, located in the RAM, the setup of the stack is complex
08:09:27 <zid> The help he needs is either 10 years to grow up or anti-psychotics, you can't provide either
08:09:29 <burzos_> zid: If I'm not worried about the cost of the syscalls, why do I need to implement the allocator in usermode?
08:09:57 <zid> burzos_: You don't, technically, I suppose, but you REALLY don't want a double-free to be a root exploit
08:10:35 <Mutabah> mobile_c_: ... pretty much
08:10:50 <zid> if the kernel is the one reading those data structures, then corruption is going to have to be dealt with /by/ the kernel, not a good recipe
08:11:05 <mobile_c_> Mutabah: and ALL registers would be capable of holding UNSIGNED values correct?
08:11:11 <zid> and if the kernel side allocator is super complicated, there's no way to use another allocator without just doubling the cost
08:11:30 <zid> say I want to use jemalloc in my program.. I have to first get blocks from YOUR allocator, which might be dlmalloc or whatever, then jemalloc on top of that
08:11:48 <zid> the kernel interface just being 'brk' or 'mmap' makes the interface clean and performance high
08:11:59 <zid> there's no real reason to do anything else
08:12:08 <burzos_> Right that's what Mutabah pointed out. But the only requirement is just that allocating page multiple blocks is fast.
08:12:12 <zid> maybe the kernel automatically grows stacks for you if you're really generous
08:12:28 <Mutabah> burzos_: And simple
08:12:34 <burzos_> Yeah, this doesn't really sound like it's a win.
08:12:47 <zid> It's a non-win and actively dangerous security wise
08:12:49 <Mutabah> burzos_: The kernel already manages at that size (it has to manipulate the page mappings)
08:13:26 <burzos_> zid: Assuming I have a correct allocator, then it shouldn't be a security problem.
08:13:35 <zid> That's the first step to a root exploit :)
08:13:45 <burzos_> If usermode does a double free, the allocator will detect it and just noop.
08:13:56 <Mutabah> That rqeuires the allocator detecting it
08:14:03 <zid> which requires super defensive data structures
08:14:06 <zid> which again, will be bug prone
08:14:13 <Mutabah> which (in the worst case) requires keeping all memory allocated until the process dies
08:14:22 <zid> and bugs in user<->kernel interfaces are called root exploit
08:14:22 <Mutabah> (i.e. making free a no-op)
08:14:30 <zid> s/t/ts
08:14:35 <zid> err s/$/s there we go
08:14:49 <Mutabah> Also, the kernel is far harder to debug :)
08:15:03 <zid> I mean, it's a fun discussion sure, but we already know the answer
08:15:06 <Mutabah> Believe us, you gain NOTHING by having malloc be a syscall
08:15:10 <klys> well, does arm have segmentation? no? then how does arm define a section or region of memory? anyone have an article on this? presumably it uses paging for that?
08:15:20 <Mutabah> klys: Paging only
08:15:24 <zid> klys: I think it has fucked up memory region stuff on some chips
08:15:29 <burzos_> Mutabah: Why does detecting a double free require keeping all memory allocated?
08:16:07 <zid> burzos_: Should a program crash because a file open failed?
08:16:56 <klys> so I need to think of it this way, a cpu without section registers, and cs and ss share address space. except paging controls writable and executable pages.
08:16:57 <burzos_> Crash? No. But lots of programs exit if they can't open a file.
08:17:14 <zid> burzos_: So why is the free syscall special?
08:17:29 <burzos_> Are we assuming there is a bug in free()?
08:17:35 <zid> no, in the user
08:17:44 <zid> it called sys_free on some already free memory
08:17:49 <zid> on any other syscall that'd be -EINVAL
08:17:58 <zid> or -ENOMEM maybe
08:18:00 <klys> /and ip and sp share address space/
08:18:07 <zid> not a program crash or kernel exploit
08:18:08 <burzos_> Ok, then my super-duper allocator detects the double free and no-ops. So then we are worried about bugs in the complex allocator?
08:18:17 <Mutabah> Eh, it might not need to keep things around forever... but it won't be as effficient
08:18:25 <zid> the bugs will be in the 'detecting the double free'
08:18:49 <zid> or me asking for weird sizes, or me freeing from the middle of a block, etc
08:18:55 <zid> none of that applies if malloc is just in userspace
08:19:08 <Mutabah> The kernel would have to sanity check everything in the metadata to avoid accidentally causing a page fault (which it would either have to recover from, or panic)
08:19:29 <Mutabah> ^ a malloc in userspace can just assume that its metadata is sane, and go and crash the process if not
08:19:45 <Mutabah> The kernel can't crash itself just because a random process did something odd
08:20:27 <zid> burzos_: Cnsider a super simple malloc implementation where I just prepend each block with a pointer to an internal metadata struct, so if I do malloc(128); I give you back a pointer that looks like [internal_ptr][ 128 bytes ]
08:20:36 <zid> (SEe: Literally every malloc implementation)
08:20:40 <zid> We can't do that as the kernel.
08:20:56 <burzos_> Yeah, because usermode could fuck with the metadata
08:20:59 <zid> Now I just have to give you [ 128 bytes ]
08:21:06 <zid> and track that block by the *address* of the block alone
08:21:14 <zid> so maybe I do something like a lookup table
08:21:30 <burzos_> Yeah that could work
08:21:31 <zid> and now consider one thread does free(ptr); and another malloc(ptr) and another malloc(ptr+3)
08:21:44 <zid> and 4 more threads do free(ptr-4) etc
08:22:05 <zid> so now you need fucking complicated locking too, as well as an expensive lookup table
08:22:14 <zid> which previously would have been O(1) it's now O(n) or whatever
08:22:40 <zid> it can't be anything decent because it has to have 0% false positive rate on seeing if a pointer is valid
08:23:03 <zid> so I can't just do say, table[ptr>>12]
08:23:03 <klys> if I follow this logic, arm stacks are delimited by empty pages. does that sound right?
08:23:40 <zid> which is what I might want to do, throw away the low bits, index bits into an array of linked lists for regions in that bucket, or whatever
08:23:43 <Mutabah> klys: All modern architectures do that
08:23:45 <burzos_> Well, memory allocators not sanitizing their inputs sounds like a good way to be exploited even in usermode.
08:23:53 <zid> usermode is not an exploit
08:23:54 <Mutabah> klys: Modern x86 OSes dont' use segmentation
08:23:55 <zid> usermode is a bug
08:23:59 <zid> in a program
08:24:10 <burzos_> If it's a suid program, it's an exploit.
08:24:12 <zid> If I write free(0xDEADBEEF); into my .c file and compile it
08:24:21 <zid> that was always going to do UB and crash/whatever
08:24:21 <burzos_> Or, if it's input coming from some network service.
08:24:26 <zid> it should *never* give a root exploit instead
08:24:28 <Mutabah> klys: Nearly every OS ensures taht there's an unmapped page just beyond the stack, so the program crashes instead of just clobbering other data
08:24:59 <zid> burzos_: UB is UB, usermode is not a managed environment
08:25:17 <zid> the kernel<->userspace interface needs to be *heavily* managed
08:25:25 <zid> all pointers need checking for validity, etc
08:25:29 <klys> mutabah, can you point to a document that states I should allocate one empty page after a stack?
08:25:43 <clever> Mutabah: gcc also adds a stack smash protector, so if you try to allocate over 4kb on the stack, it will touch each page from the old stack-pointer, to the new one
08:25:56 <clever> Mutabah: so an attacker cant allocate something big enough to skip over that guard page
08:28:09 <Mutabah> clever: yep, or just so a programmer can't do it accentally :)
08:28:16 <Mutabah> klys: It's a defensive measure
08:28:18 <burzos_> zid: Well if you believe that about usermode, why use stack canaries? The program is invoking UB, so it's on its own.
08:28:21 <clever> zid: what about the fact that the only users capable of writing to the metadata before your malloc'd block, already have ring0?
08:28:35 <zid> clever; Inorre
08:28:38 <zid> Incorrcet
08:28:53 <zid> You might want to read the backlog
08:28:55 <clever> zid: in what case would you be exposing that to a userland process?
08:29:10 <zid> clever: Exactly, go read the backlog
08:29:22 <zid> burzos_: You've got a seriously twisted view of security/computers/oses somewhere
08:29:31 <clever> how far back?
08:29:33 <zid> burzos_: People wouldn't use computers if userspace was managed
08:29:47 <zid> clever: The bit where he asked why people don't mke malloc a syscall
08:29:51 <zid> that should be enough context though tbh
08:29:51 <klange> eh, dunno about that
08:29:59 <zid> klange: They'd just use ones that aren't
08:30:00 <Mutabah> burzos_: It's entirely possible to write a safe syscall malloc - but what does it get you?
08:30:02 <zid> called unsafeputers
08:30:06 <clever> ahh, yeah, thats just a recipe for disaster
08:30:13 <klange> no managed userspace OS has gotten far enough to really find out if they'd gain traction
08:30:30 <clever> an malloc syscall would both ruin performance (more context switches), and the metadata would be open to attack
08:30:30 <burzos_> No doubt I'm seriously twisted. But why more userspace mgmt hurt users?
08:30:31 <zid> klange: Because there's no demand because nobody wants them, you just use a managed language instead
08:30:39 <klange> end users don't care, as long as they can get their facebooks
08:30:52 <burzos_> clever: Well we talked about the syscall bit, but certainly the metadata has to hang out in the kernel.
08:31:06 <clever> yep
08:31:17 <zid> burzos_: Here's an OS safe from usermode bugs causing system ownage: no fork(), no pages can be made executable after program start, etc
08:31:28 <zid> congratulations you're now a nokia 3310
08:31:33 <Mutabah> zid: ROP :)
08:31:36 <clever> semi-related, threadx and palmos both have an odd memory model, where you dont actually get the address of something when you allocate it
08:31:37 <klange> do i have snake?
08:31:43 <clever> the allocate function just returns a handle
08:31:55 <clever> and you then have to call a lock function to get its current address, and unlock when your done
08:31:55 <zid> clever: Won't work to implement C
08:31:55 <Mutabah> zid: It's surprising how much you can do just by manipulating the return address
08:32:12 <clever> so you only know the address when you are holding the lock
08:32:20 <zid> Mutabah: You'd be surprised how little that works if you can't use those gadgets to build shellcode though, and you can't fork to a shell etc
08:32:53 <clever> zid: oh, and ive seen a port of linux, that lacked fork(), but still "worked"
08:33:06 <clever> zid: the target cpu had no MMU!!, and the linux kernel only had vfork()
08:33:09 <zid> clever: They're called nokia 3310s :P
08:33:20 <zid> You pick the preinstalled program from the list
08:33:23 <zid> that is your entire computer
08:33:49 <burzos_> That's way more insane than just sanitizing inputs to allocator functions.
08:34:06 <zid> Meanwhile the guy with the OS that allows unmanaged userspaces has crysis
08:34:07 <clever> zid: the linux fork i mentioned, could still make more processes at runtime
08:34:23 <zid> clever: Then it had fork you just pretended it didn't
08:34:31 <clever> zid: it only had vfork()
08:34:34 <zid> so, fork
08:34:40 <clever> which suspends the parent until the child does execve
08:34:58 <clever> and because it lacks an mmu, it then assigns the child to another non-conflicting region of ram
08:35:28 <clever> mmap/brk and the initial layout on startup are all non-conflicting
08:35:31 <zid> burzos_: Which do you buy for your desktop machine, can run crysis or can run snake? :P
08:35:42 <zid> machine has the same specs, costs the same
08:36:00 <corecode> hi
08:36:06 <klys> hi
08:36:15 <zid> oh we're an aol chat room now? *changes the banners*
08:36:24 <corecode> so i tried writing some code in rust yesterday
08:36:32 <burzos_> Fair enough, but on the other hand containers are like a new attempt at doing managed userspace.
08:36:32 <corecode> oh boy did they overdo it with the complexity
08:36:45 <zid> no, they're really not
08:37:04 <corecode> it seems i need to write 10-20 lines to implement a new error return?
08:37:13 <klange> containers are just resource isolation and fancy chroots.
08:37:26 <zid> lemme find the link
08:37:28 <klange> and they're not a security mechanism in any of the popular forms
08:37:35 <burzos_> FreeBSD jails?
08:37:54 <zid> I am fairly sure it is linked frm this page.. but fuck if I can find it
08:38:42 <burzos_> Processes (ie, virtual address spaces) are rudimentary usermode management.
08:38:55 <burzos_> Containers are just trying to bolt stuff onto a too-simple process model.
08:39:47 <zid> dang can't find it
08:40:31 <zid> "We put virtual machines inside Linux, and then we put Docker inside virtual machines, simply because nobody was able to clean up the mess that most programs, languages and their environment produce. We cover shit with blankets just not to deal with it"
08:40:44 <zid> That's why people use docker
08:40:48 <klange> basically
08:40:48 <geist> klys: no
08:40:50 <klange> it's good at it
08:41:54 <zid> https://xkcd.com/1987/ relevent xkcd
08:41:54 <bslsk05> xkcd - Python Environment
08:42:57 <zid> https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript If you want a good talk (about half way in but don't just skip to it) featuring 'lets' just manage userspace'
08:42:58 <bslsk05> www.destroyallsoftware.com: The Birth & Death of JavaScript
08:43:29 <corecode> who is arguing what side?
08:43:49 <zid> what side of what
08:44:01 <corecode> seems you are arguing about something
08:44:09 <zid> nope
08:44:14 <geist> zid just does that sometimes
08:44:15 <corecode> ah you are agreeing
08:44:18 <corecode> okay
08:44:19 <geist> takes a while to calibrate to em
08:44:22 <corecode> :)
08:44:23 <zid> I was giving resources for a thing
08:44:30 <corecode> hi geist
08:44:34 <geist> hola
08:44:56 <corecode> i was really hoping that rust would be a good platform for embedded code
08:44:58 <burzos_> NixOS is another potential avenue for cleaning up userspace
08:45:02 <zid> geist: pfft that was the most real-world like conversation this place has had in forever
08:45:14 <corecode> but it feels a bit complicated
08:45:26 <zid> Rust doesn't fit the niche it went for, whoops
08:45:44 <corecode> hehe
08:45:48 <geist> http://gordonbell.azurewebsites.net/cgb%20files/design%20and%20behavior%20of%20tss8%20ieee%206906%20c.pdf is a fun page. a little paper, written in mid 70s about a little time sharing os on pdp8
08:45:49 <bslsk05> gordonbell.azurewebsites.net <no title>
08:45:58 <zid> don't mind geist, you get used to him
08:46:15 * geist waves
08:46:21 <zid> Honestly though if you guys haven't watched that javascript talk I recommend it it's really good
08:46:45 <burzos_> Not sure I want to willing subject myself to javascript outside of work
08:46:52 <zid> it's not about javascript
08:47:22 <zid> It's about the world of computing, focusing on javascript, why we have a fucked up language like it, what people who like it are going to try and ruin our lives doing, etc
08:47:35 <zid> and it's a brilliant piece of comedy/parody
09:08:16 * klys waves back
10:42:29 <oo_miguel> what should I do to my file descriptors on fork? duplicate them?
10:42:52 <zid> depends what the semantics of your fork() are
10:43:00 <oo_miguel> zid: what are my options?
10:43:05 <zid> yes and no
10:43:10 <oo_miguel> or better: what are common solutions?
10:43:13 <zid> yes
10:43:17 <zid> and in 2nd, yes
10:43:25 <zid> I think yes also comes in third
10:43:26 <oo_miguel> heh
10:45:02 <oo_miguel> My concern is that forking without duplicating, and using them in both processes, will get them closed once one of the forked processes finishes
10:45:07 <klange> fork is a unix concept and thus its semantics are dictated by what a unix should do, thus fork should create a clone of the whole process, inclusive of its file descriptors; this is fundamental in things like shells setting up pipelines
10:45:33 <oo_miguel> klange: yes, pipelines are exacltly what I am going for next
10:45:45 <oo_miguel> this is why I encountered this question
10:45:55 <zid> fwiw, linux style pieps are unidirectional, so you don't actually have duplicate FDs
10:46:08 <zid> and shell style pipes dupe them over stdin and stdout, so the only duplicate fd is stderr
10:46:45 <oo_miguel> zid: what I saw the pipe system calls returns two filesdescriptors, and each of the forked proceses closes one of them using the oteher one and vice versa
10:46:55 <zid> yep
10:47:19 <zid> so each gets one end of a pipe, fd 4 and fd 5 for example are open in each process respectively and point to different ends of a single pipe
10:47:32 <oo_miguel> "my pipes" just return a single fd which I can read to and write from ... I wonder if I might run into problems with this approach
10:47:34 <zid> then you'd normally close stdin or stdout respectively and dup over them
10:47:54 <oo_miguel> I also find this dup() stuff very ugly
10:47:56 <zid> oo_miguel: on unixy pipes you end up with severe deadlocking issues unless you write very good protocols
10:48:05 <oo_miguel> why can I not simply have a system call to reroute stdin, stdout etc
10:48:11 <zid> they do, it's called dup
10:48:13 <oo_miguel> to change their underlying file descirptor
10:48:16 <zid> rename it if you want
10:48:43 <zid> err non-unixy pipes
10:48:50 <zid> if you go for bidirectional
10:49:05 <zid> you also can end up with weird issues like the child trying to read the thing it sent to the parent as the response from the parent :P
10:49:12 <zid> you genuinely need a real wire protocol with sleeps and shit
10:50:22 <oo_miguel> zid: yeah I saw this dup() call on linux, but I wonder why not to have simply a call as: change_underlying_fd(stdout,somepipe);
10:50:35 <zid> can do if you want, dup is less typing
10:50:55 <klange> stdout is just an opaque FILE*
10:51:08 <oo_miguel> dup takes the internal fd numbering into acount right?
10:51:16 <klange> most things in unix-like stuff may even have baked in references to fds 0, 1, 2
10:51:26 <oo_miguel> so if I do not close stdin 0 1 2 it will be assigned to something random from my perspective?
10:51:43 <zid> no, 3
10:51:50 <zid> fds always go sequentially
10:52:38 <oo_miguel> hmm, and what does 3 point to in a fresh main(){..} ?
10:52:58 <zid> nothing, if you create an fd that's what number it will have
10:53:20 <oo_miguel> ok guess I should play a bit with them under my regular linux
10:53:30 <zid> "dup() uses the lowest-numbered unused descriptor for the new descriptor. "
10:53:48 <oo_miguel> I just use them from the shell without beeing much aware about the internal syscalls
10:53:50 <zid> it takes an argument, the descriptor to copy
10:54:20 <zid> the only valid ones at program start would be 0 1 2, so dup(0) dup(1) or dup(2) would create fd 3 which is a copy of one of those guys
10:55:24 <oo_miguel> aaah ok right
10:55:54 <oo_miguel> and closing one of them , creating a pipe, and calling dup(mypipe_fd); will copy it to one of the 0 1 2 right?
10:56:04 <zid> up
10:56:08 <oo_miguel> ok makes sense
10:56:23 <zid> well the order of the first two things is wrong
10:56:26 <klange> you want to use dup2 to ensure you are replacing the correct thing
10:56:32 <zid> but yea, use dup2
10:56:41 <klange> dup2 does the close as well
10:56:54 <oo_miguel> right, I read that dup is vulnerable to an interrupt coming between closing and duping. but why?
10:57:04 <klange> which is important because otherwise you have a potential race if you close + dup yourself in the hopes that you'll get the right fd
10:57:31 <oo_miguel> how could the context switch (or what am I afraid of?) cause my close to get reverted??
10:57:59 <zid> https://gist.github.com/zid/b2be8e37edc0e9133e27b88e94037e0e here's my shitty bi-directional pipe testrig :P
10:58:00 <bslsk05> gist.github.com: .c · GitHub
10:58:04 <klange> idk about an interrupt at the base level, but definitely in a threaded environment if you were opening things somewhere else you could end up with your other open taking your newly closed fd
10:59:00 <oo_miguel> klange: ah probably the vulnerablity applies only when I have multiple threads. allright
10:59:25 <oo_miguel> otherweise, as we said, each process maintains each own set of fd's
11:01:23 <oo_miguel> ok thanks all, and thank you for the example code zid! I will try to implement something similar to dup2. AND at first duplicate my filedescriptors on each fork (I do not do that yet)
11:01:47 <zid> test it with a single process first imo
11:02:00 <zid> write dup2 first so that you can have multiple copies of the same thing
11:02:06 <zid> and get your refcounting or whatever working
11:02:19 <zid> then it's one more thing that pre-done for when you do fork
11:02:22 <klange> yeah, that was more interesting part of it
11:09:06 <oo_miguel> I will increase a counter on each fork, and decrease on each close, Does this make sense?
11:09:34 <oo_miguel> Also I have to test how writes to such duplicted file descriptor are handled usually
11:09:55 <zid> oo_miguel: they both describe a certain *file*
11:09:58 <zid> the write goes to the file
11:10:05 <oo_miguel> to the end?
11:10:07 <zid> the descriptor is just a thing keeping the file in the open state
11:10:13 <oo_miguel> and writes get interlaeved?
11:10:51 <oo_miguel> hmm I also keep track of the current position in my file descritor structure
11:11:05 <zid> that seems good
11:11:32 <oo_miguel> after duplication I will track the position for each process on its own I imagine
11:12:10 <zid> You should probably read how whatever it is you're trying to copy works, linux I guess?
11:12:17 <zid> make some test cases for linux for you to fail
11:12:36 <oo_miguel> yeah, I guess it is time for some experimenting. you already helped me very much
11:12:47 <oo_miguel> I am loosly basing my toy kernel on linux
11:12:58 <zid> yea it's just easier that way honestly
11:13:08 <zid> but I like your approach of not just blindly copying its behaviors
11:13:14 <zid> get a feel for how they work and try to figure out why etc
11:13:51 <oo_miguel> ehehe yeah, I just implement something as I feel, only to find out that I should change it to the "linux-way" after a while
11:13:58 <zid> perfect
11:14:20 <oo_miguel> but I treat my toy-kernel as an educational experience so I am happy
11:14:31 <oo_miguel> anyway thanks. I will surely be back soon ;)
11:20:16 <klange> I think most of us are here to learn. Very few people end up here who are trying to do otherwise.
11:20:26 <klange> We just don't really get the academic types...
11:20:35 <klange> The ones working on research OSes.
12:00:09 <oo_miguel> klange: as minix or which one are you referring to? excuse my ignorance :P
12:00:44 <klange> minix is not really the sort of thing I have in mind as an academic project
12:00:54 <klange> but we also don't get "minix devs" here either
12:01:37 <oo_miguel> I am thinking about putting something very innovative or experimantal in my toy-os one day. However I lack so much of the basic understanding how a regular os (i.e linux) works that I am aware I might not even ever come up with such an idea.
12:01:39 <klange> Academic projects are research projects made with the goal of testing some new idea.
12:02:13 <klange> Something someone builds so they can write a paper on some new idea of how operating systems should work.
12:02:34 <oo_miguel> most of my "os ideas" can be reduced to writing some linux user-space programm :P
12:03:14 <klange> In my eyes there's effectively three kinds of OS projects: Hobby projects, academic projects, and professional projects. The latter is extremely rare, but we can look at Fuchsia as an example.
12:03:40 <oo_miguel> I am also quite impressed by the concept of microkernels (which in fact seem to be the absolute opposite of my toy-kernel) :P
12:06:12 <oo_miguel> I suppose the majority of projects are toy kernels that print "Hello World" in real mode. A state my kernel basically was for a long time.
12:06:40 <sham1> Well even if most projects could be reduced to something running on other OSes as an userland program, it's still good practice
12:10:01 <oo_miguel> It is jus a bit disillusionig that after many hours of work my toy-kernel offers a buggy subset of some linux system calls without adding annything that could not be done there :P
12:10:33 <oo_miguel> ... but anyway tinkering on it makes me happy
12:11:47 <sham1> Well if we were about practicality here most of us wouldn't be doing this
12:11:59 <sham1> So clearly there is something else going on
12:14:50 <oo_miguel> Maybe it is satisfying to imagine, that stranded on an desert island only with a laptop running some proprietary OS, one would be capable of crafting his own one...
12:21:45 <klange> Rob Pike once famously gave a talk titled "Systems Software Research is Irrelevant".
12:22:35 <klange> While there's people out there working to make Linux or NT or whatever more efficient at some task, ultimately we're not likely to see another big player with some new ideas of operating system design come into the big picture.
12:27:39 <klange> If you want a sense of having built something unique that solves a problem, languages are probably a better bet - but I'd also say you probably missed the boat for this season, maybe try again a few years.
12:28:29 <klange> I think the vast majority of people we get in this community don't care about new ideas. Instead, their primary thought process is one of NIH. They don't want to make a new OS because they think there's some problem to solve in operating systems design - if they do, it's probably something hilarious misguided.
12:28:39 <klange> They want to write an OS because they want to *write an OS*.
12:28:56 <klange> And that is a perfectly, 100% reasonable reason to want to do something.
12:29:20 <sham1> Besides, this stuff is fun
12:30:02 <glauxosdever> Except when it breaks :p
12:30:13 <sham1> Well that's a thing
12:30:17 <klange> Sometimes it's even more fun when it breaks :)
12:30:34 <glauxosdever> If it breaks in a spectacular way and you know how to fix it, sure
12:30:58 <glauxosdever> If you spend full months trying to fix something, it's not really fun
12:31:09 <sham1> Or if you spend full months fixing it and finally figure it out
12:33:01 <glauxosdever> Ok, it depends how persistent you are about something. Over the years, I have shifted from being very persistent about things into not being persistent at all. And this is what has caused that during the last two years I didn't do anything worthwhile programming-wise
12:33:20 <glauxosdever> It sucks
01:33:32 <mischief> .theo
01:33:32 <glenda> But you decided you are special, and don't want us to help us help you.
01:47:45 <glauxosdever> .theo
01:47:45 <glenda> Read the man page again!
01:47:50 <glauxosdever> I'll do!
01:49:28 <sham1> .theo
01:49:29 <glenda> Come on. Read it carefully.
01:53:39 <klange> glenda continues to ooze sentience.
02:01:21 <rain1> https://uefi.blogspot.com/2012/10/gnu-efi.html
02:01:22 <bslsk05> uefi.blogspot.com: UEFI: GNU EFI
03:17:33 <Ameisen> Any of you guys done any benchmarks between Linux' syscall ABI and BSD's syscall ABI?
03:17:39 <Ameisen> and possibly other ABIs?
03:17:51 <Ameisen> the texts I've read suggest that BSD's overall should be sliiiiightly faster
03:18:33 <Ameisen> since it has the arguments on the stack, you don't have dual register pushes potentially
03:19:00 <Ameisen> though I'm not sure why the kernel would need to save/restore the registers with kernel args, it should just be able to, well, not use them for anything other than reading.
05:20:25 * geist yawns
05:48:26 <Prf_Jakob> geist: Morning (UGT)
05:50:19 * geist waves
06:55:00 <oo_miguel> join #wine
06:55:07 <oo_miguel> aaah sorry
06:55:15 <oo_miguel> missed the leading slash
07:57:52 <Shockk> I'm trying to compile dash right now and it doesn't seem to be picking up on the fact that I've defined the strsignal function
07:58:13 <Shockk> i.e. when I run configure, I see: checking for strsignal... no
07:58:41 <Shockk> is there something special I need to do, in addition to actually defining it, before it'll see it?
08:02:23 <froggey> check config.log to see how it's actually trying to detect it
08:03:13 <Shockk> oooh I actually need to give it a body
08:03:44 <Shockk> I didn't give it a body assuming it'd just fail to link while building and then I'd resolve it at that time
08:03:59 <Shockk> didn't realize the configure script would see through my trickery
08:04:52 <johnjay> Shockk: what are you woworking on?
08:05:01 <johnjay> the barebones kernel?
08:05:18 <Shockk> right now my own libc, and trying to build dash with it
08:07:32 <johnjay> eh, i see
08:07:41 * johnjay shudders to think what the glibc sources look like
08:07:50 <Shockk> so do I
08:09:05 <Shockk> I'm not sure yet if I want to write my own shell; but for the time being, dash seems like a good thing to work on porting
08:09:27 <Shockk> my libc is only a fraction complete so it's requiring me to add a lot of stuff to suppor tit
08:09:32 <Shockk> support it*
08:12:48 <johnjay> someone said something in here before i wish i wrote down
08:13:07 <johnjay> it was like to make your own OS you need A) kernel, B) shell, C), compiler, idk something else
08:13:16 <Shockk> libc?
08:13:22 <Shockk> bootloader?
08:13:44 <Shockk> so far I only have a bootloader, kernel, and 8% of a libc
08:14:00 <johnjay> right. i guess my question would be why you need a libc and a compiler
08:14:09 <johnjay> but i suppose this is not necessarily embedded
08:14:19 <johnjay> do embedded systems have c compilers?
08:14:31 <Shockk> usually
08:14:45 <Shockk> they're often based on gcc though, from my experience
08:14:48 <bcos_> Windows10 doesn't even come with a compiler
08:15:19 <Shockk> some more recently are based on clang/llvm
08:15:33 <johnjay> i always though llvm was just an apple thing for some reason
08:15:39 <johnjay> but it's quite mainstream isn't it
08:16:26 <Shockk> not sure how widespread its use was before apple began working on it and using it
08:16:39 <Shockk> but it's used in loads of places aside from apple now
08:17:16 <Shockk> the company I work for uses it for stuff like opencl and sycl for custom architectures and stuff like that
08:17:39 <Shockk> that probably makes me extremely googleable but I don't mind
08:17:56 <johnjay> opencl is basically just running your program on a gpu right?
08:18:09 <Shockk> sort of
08:18:26 <Shockk> basically you have some code that gets run massively in parallel
08:18:54 <johnjay> is this your yt chan?
08:18:56 <johnjay> https://www.youtube.com/user/shockwave0eternal/videos
08:20:21 <Shockk> hmmm.... well that custom url is from 12 years ago lol, I prefer the one that doesn't look ridiculous, but yes
08:20:30 <Shockk> no way for me to remove it though
08:20:49 <johnjay> idk it's just what youtube gave me
08:21:31 <Shockk> I was going to say anyway, the way that opencl works is different to the normal model of programming
08:21:37 <johnjay> i love that To Zanarkand, I remember the first time I got pcsx2 to run on a decent pc
08:21:46 <johnjay> cranked up the graphics and played the intro, was really cool
08:22:31 <Shockk> normally you write code that has a single threads of execution, and sometimes you explicitly add extra threads of execution with different code
08:22:54 <johnjay> whereas opencl is the reverse?
08:22:55 <Shockk> for opencl your single set of code executes across a large group of data, where what distinguishes each instance is just some instance id
08:23:07 <johnjay> pj
08:23:08 <johnjay> *oh
08:24:01 <Shockk> my opencl c is a bit rusty currently but
08:24:52 <Shockk> kernel void add_one(int *a, int *b) { size_t id = get_group_id(0); b[id] = a[id] + 1; }
08:25:54 <Shockk> then you invoke it with a buffer of, say, 4096 ints, and your resulting buffer would have each of the values + 1
08:29:38 <johnjay> i see
08:29:47 <johnjay> so instead of a pointer to an int it's a pointer to 4096 ints?
08:30:02 <Shockk> well I mean it's a buffer pointer
08:30:11 <Shockk> just like char*
08:30:37 <johnjay> right
08:31:05 <johnjay> in K&R C you have a function prototype like func_sort(int *x, int size n)
08:31:29 <johnjay> but there's nothing about 4096 in there is what i meant
08:31:45 <Shockk> ah right, no, because note that the code isn't doing any looping
08:32:17 <Shockk> instead there's an invocation of that code, for each id in the workgroup
08:32:57 <Shockk> so the workgroup id is your index into the buffer argument
08:35:15 <johnjay> ok. am i correct to imagine 4,096 continuous ints then?
08:35:29 <johnjay> so the id is just an offset multiplied by something
08:39:45 <burzos> Shockk: Is your syscall interface POSIX-like?
08:40:26 <Shockk> sorry I was drawing a picture
08:40:29 <Shockk> johnjay: https://i.imgur.com/KYiN4rT.png
08:41:02 <Shockk> burzos: I don't have much of an interface yet but kind of yes; I have an interface so far similar to newlib's, I have open, read, and write so far
08:41:30 <johnjay> Shockk: hrm, what's host and device?
08:41:36 <johnjay> yes nice ms paint there
08:41:39 <Shockk> :D
08:41:55 <burzos> Why do you implement your own libc instead of porting musl or uClibc?
08:42:29 <Shockk> host is your regular machine, i.e. an x86 machine where you're running the code that connects to the opencl device
08:43:17 <tyler569> burzos: why do you implement your own kernel instead of using linux or bsd?
08:43:33 <Shockk> device is the opencl device with some number of general-purpose computation cores
08:43:42 <burzos> I'm not telling him not to do it. Was just curious if he had some specific reasons
08:44:00 <Shockk> burzos: I mean, I could have ported something like those, but I felt like I would get a lot more learning out of building my own
08:44:17 <burzos> Fair enough
08:46:20 <Shockk> porting newlib wasn't too difficult of a thing to do, but I imagined it'd be trickier to port something more sophisticated, and it'd also not teach me anything apart from how to port it
08:46:30 <johnjay> i'm trying to find an online white board that isn't spammy Shockk
08:46:53 <johnjay> this one has a really basic interface: https://whiteboardfox.com/146262-9237-8032
08:46:54 <bslsk05> whiteboardfox.com: Whiteboard Fox
08:50:07 <johnjay> oops i already closed it
08:54:49 <johnjay> anyway thanks for the idea Shockk
08:54:57 <johnjay> honestly with something like OpenCL i know my card supports it
08:55:08 <johnjay> i'd just be terrified to actually try getting some kind of example or demo working
08:55:23 <johnjay> userland is wasteland, everytime i try to install or compile something it breaks
09:13:48 <graphitemaster> I must be having a brain fart today but I literally forgot how to undo a multiplication
09:14:54 <graphitemaster> I was like okay I have this scalar I'm multiplying by another scalar that is fractional, so something like 0.15 and I'm passing this around everywhere but here I need the non-scaled scalar and I couldn't think of the operation to undo it
09:15:13 <graphitemaster> I mean obviously it's division but my brain crapped out for some reason might be time to go to bed
09:15:27 <mischief> look its graphitemaster https://www.dailydot.com/wp-content/uploads/f10/f1/686bf45f96ce06af9dd5324453868273.jpg
09:15:58 <graphitemaster> yeah but this is simple maffs
09:17:51 <johnjay> taht's basically why divison was invented in the first place
09:17:56 <johnjay> i.e. how to undo multiplication
09:18:20 <graphitemaster> I think there was a part in my brain that was like "yeah but you can't use divide because the number isn't a whole number"
09:18:58 <johnjay> eh i take fractional exponents all the time, i literally don't give a damn
09:19:25 <graphitemaster> now how do you undo multiplication without a divide that's the question
09:19:38 <graphitemaster> the hundred million dollar question
09:20:09 <[REDACTED]> bitshifts
09:20:12 <clever> mischief: i booted plan9 by mistake on a random core2 quad, good news, it boots, lol
09:20:18 <johnjay> multiply by the inverse of course! :p
09:20:27 <mischief> how do you boot an os by mistake
09:20:29 <[REDACTED]> (i mean it's technically just implementing division, but still)
09:20:31 <mischief> .theo
09:20:31 <glenda> Incorrect.
09:20:36 <graphitemaster> .theo
09:20:36 <glenda> Oh sorry, I forgot to think like an American for a second there.
09:20:40 <graphitemaster> ouch
09:20:40 <clever> mischief: i was running thru a pile of usb sticks, not sure which one had nixos on it
09:20:49 <clever> mischief: first one to boot was your image, lol
09:20:49 <graphitemaster> right I could multiply by the inverse
09:20:54 <johnjay> clever: i bought some labels to use for that purpose
09:21:07 <clever> mischief: what was the command to upload the sysinfo?
09:21:47 <mischief> what is my image
09:21:51 <johnjay> graphitemaster: of course my intuition would be to say something like the inverse of 0.15 is just 6, but i assume for computing you have to be more exact
09:22:00 <mischief> clever: sysinfo -p
09:22:07 <mischief> needs networking up of course
09:22:07 <clever> mischief: the usb stick i was testing the plan9 stuff on a week or 2 ago
09:22:12 <mischief> ah
09:22:29 <johnjay> maybe there's a name for that interpolating thing where you computing inverse of .1 is 10 and inverse of .2 is 5 and then you average 10 and 5 to get 7.5 lol
09:23:06 <graphitemaster> johnjay, well somewhat ironically the 0.15 comes from calculating an inverse anyways, I think I can just pass that along and undo >_>
09:23:07 <clever> mischief: its got 3 nic's and i dont remember how to bring up networking
09:23:17 <graphitemaster> because I wanted to avoid the initial divide there
09:23:25 <mischief> execute ip/ipconfig, if you've not done any other configuration
09:23:37 <mischief> it will use the 'first' nic probed
09:25:07 <clever> mischief: what about listing all known interfaces, and checking the link status with mii?
09:25:34 <mischief> thats not how shit works in plan9.
09:27:18 <mischief> clever: you can find link status easily, but making the dhcp client run on all of them is silly.
09:27:39 <clever> i just want to know which one has the link, so i can run it on the right one
09:27:45 <clever> or move the cable to the "1st" one
09:28:30 <johnjay> graphitemaster: subtract 15 from 100 repeatedly then use that as the estimate. XD
09:28:55 <johnjay> sorry i'll shut up now
09:31:26 <clever> mischief: hmmm, moving the cable and re-running `ip/ipconfig` shows that 2 ports result in a dhcp error, but the "LAN1" port on the motherboard results in no output
09:31:40 <clever> so i probably had the right port the first time
09:31:55 <mischief> :)
09:32:13 <mischief> clever: you read the ether's stats file and look for the line beginning 'link: '
09:32:24 <mischief> ethers besides the first aren't bound by default
09:33:07 <clever> which dir is the ether file in?
09:33:52 <mischief> clever: the nonzero ones need to be bound
09:33:59 <mischief> the zeroth interface is bound into /net
09:34:07 <clever> just found /net/ether0
09:34:09 <mischief> grep link /net/ether0/stats
09:34:29 <mischief> for the others:
09:34:36 <mischief> bind -a '#l1' /net ; bind -a '#l2' /net
09:34:59 <mischief> if you want to dhcp on them you have to tell ipconfig explicitly which ether to use
09:35:16 <clever> link is 1
09:35:59 <mischief> we get signal.
09:36:56 <clever> mischief: but sysinfo -p still hangs
09:38:16 <mischief> dns busted?
09:38:27 <mischief> got ip/dns in /net/ndb?
09:39:56 <clever> mischief: /net/ndb has 3 ip's (173, 174, and 175) and each has a dns entry, which is correct
09:40:20 <clever> likely a side-effect of re-running ip/ipconfig
09:40:51 <mischief> are they all on the stack?
09:40:55 <mischief> check /net/ipselftab
09:41:07 <mischief> also /net/iproute
09:41:35 <clever> 173 is missing, 174&175 have the same numbers
09:42:16 <mischief> easiest thing todo would be reboot and ipconfig again
09:42:21 <mischief> resetting the ipstack is kinda painful
09:43:32 <mischief> oh
09:43:37 <mischief> maybe its not as bad as i thought
09:43:46 <clever> already rebooting, heh
09:43:49 <mischief> i *think* ip/ipconfig unbind /net/ether0 -
09:43:52 <mischief> ok
09:45:25 <clever> arpreq: 0.0.0.0 also has ether addr *hexdigits*
09:45:35 <clever> mischief: this appears when i run `ip/ipconfig` and sysinfo -p still hangs
09:46:50 <mischief> clever: i think thats a leftover debug print
09:47:04 <mischief> you got dns in /net/ndb?
09:47:11 <clever> mischief: the digits it prints are from /net/ether0/addr
09:47:31 <clever> mischief: yes
09:48:02 <mischief> clever: ndb/dnsdebug 9front.org
09:48:10 <mischief> that will probably just query the root servers
09:48:23 <mischief> but that will at least test to see if routing works
09:50:07 <clever> mischief: both kernel and terminal messages printed out, so its a bit garbled, but i do see that gandi.net is hosting the dns
09:50:13 <clever> so it appears to be getting an answer
09:50:41 <mischief> hm, that should probably be cleaned up.
09:51:01 <mischief> clever: what about running ndb/dnsquery
09:51:05 <mischief> and typing 9front.org
09:51:14 <mischief> that should only use the resolver in ndb
09:51:17 <mischief> not root servers
09:51:36 <clever> the kernel messages say something about it crapping out
09:52:44 <clever> mischief: https://cdn.discordapp.com/attachments/244608326552387584/492090629531238401/JPEG_20180919_185524.jpg
09:54:04 <mischief> you can make a new rio window or move the old one around to clean up the framebuffer
09:54:30 <clever> scrolling up/down cleaned up the window i was using
09:54:37 <clever> dnsquery does return the right ip
09:55:21 <mischief> but sysinfo hangs?
09:55:33 <clever> yeah
09:56:40 <mischief> strange
09:56:54 <johnjay> who's talking about rio
09:57:02 <johnjay> that thing is some nightmare from another dimension
09:57:11 <johnjay> where you have to use weird mouse buttons!
09:57:13 <mischief> .theo
09:57:13 <glenda> There is no policy.
09:57:25 <mischief> clever: what about: mothra http://sysinfo.9front.org
09:57:27 <bslsk05> sysinfo.9front.org: 9front/sysinfo
09:58:56 <clever> mischief: just says mothra! and 9front/sysinfo
09:59:37 <clever> mischief: wait a sec, how do i check free disk space?
10:01:43 <mischief> if you installed with hjfs, echo df >> /srv/hjfs.cmd
10:01:49 <mischief> depends on the file server.
10:02:23 <clever> mischief: 0mb free
10:02:40 <clever> mischief: last thing i did with this usb stick was try to rebuild everything, with too small a partition
10:02:44 <john_cephalopoda> Forth is pretty pretty.
10:03:08 <clever> mothra and sysinfo -p appear to handle lack of disk space badly
10:03:08 <john_cephalopoda> Oops, wrong channel.
10:04:00 <mischief> clever: uh, it sounds to me like mothra worked
10:04:12 <mischief> clever: you could just delete some files
10:04:16 <clever> mischief: it didnt show the page that chrome showed with the same url
10:04:25 <mischief> clever: scroll down.
10:04:27 <clever> yep, just need to know what files are safe to delete
10:04:35 <clever> ah, window was probably just too small then
10:04:39 <mischief> mothra doesn't render css or js.
10:04:49 <clever> it was only a single line of text
10:04:53 <clever> and no obvious scroll bar
10:10:18 <mischief> clever: echo $objtype
10:10:45 <clever> mischief: i did `rm -r /root/dist` and now http://sysinfo.9front.org/src/232/body works
10:10:56 <clever> the usb stick needs to be wiped anyways, the rootfs is too small to build 9front
10:11:09 <mischief> there goes your hg repo
10:11:10 <mischief> oh well
10:11:35 <clever> the disk cant hold a partial build, so it has to be reinstalled from scratch anyways
10:12:11 <clever> but you now have sysinfo for a random piece of hardware it appears to support
10:13:36 <mischief> your disk controller is fucked
10:13:43 <clever> the sata one?
10:14:14 <mischief> are there any real disks in the machine?
10:14:33 <clever> there is a single sata drive plugged into data, but not power
10:14:39 <clever> i need to find a sata power adapter
10:14:42 <mischief> that explains it
10:15:07 <clever> mischief: no, https://plus.google.com/u/0/photos/albums/p6cfufpv03jsti8i63220p916oivla86p?pid=6602747446692852706&oid=111581433845907259745 explains it
10:15:28 <mischief> 404
10:15:38 <clever> https://r5---sn-ab5l6ndy.googlevideo.com/videoplayback?id=376da3d49ee9eb8d&itag=37&source=picasa&begin=0&requiressl=yes&mm=30&mn=sn-ab5l6ndy&ms=nxu&mv=u&pl=22&sc=yes&ei=YsqiW-SCFIKi-QWuk66QCQ&susc=ph&app=fife&mime=video/mp4&cnr=14&dur=11.935&lmt=1537322018471147&mt=1537394839&ip=156.34.44.71&ipbits=0&expire=1537402498&sparams=ip,ipbits,expire,id,itag,source,requiressl,mm,mn,ms,mv,pl,sc,ei,susc,app,mime,cnr,dur,lmt&signature=3F9632F76806F024A3FED501C7CF5F
10:15:45 <clever> damn google, lol
10:16:07 <clever> let me re-upload to youtube
10:16:35 <mischief> https://streamable.com/ ?
10:16:36 <bslsk05> streamable.com: Streamable - video for publishers
10:16:49 <clever> mischief: https://youtu.be/5oYlxS8DRH4
10:16:50 <bslsk05> 'dead PSU' by michael bishop (00:00:12)
10:17:21 <mischief> i'm not an expert but that seems bad
10:17:27 <clever> mischief: that was plugged into the motherboard when i first powered it up
10:17:33 <clever> the machine is lucky to event turn on :P
10:19:21 <johnjay> is it possible to use gdb to debug in virtualbox?
10:19:39 <johnjay> i know there's a built in debugger but i can't see anything recent on using gdb, just some VBoxGDB thing from 4.0
10:19:40 <clever> johnjay: it would probably be simpler to boot the target in qemu
10:20:21 <johnjay> ok i had that thought, wasn't sure if maybe vbox had a gdb stub or not
10:46:56 <Shockk> well I made progress now
10:46:59 <Shockk> dash compiels!
10:47:03 <Shockk> dash compiles!*
10:47:12 <Shockk> it just doesn't link, but that's understandable
10:47:23 <rain1> well done
10:55:16 <clever> mischief: interesting, the nvram in 9front's sysinfo is longer, and disagrees with linux's /dev/nvram
10:58:19 <mischief> the rtc/nvr driver in 9front is probably old and dumb
10:58:29 <mischief> i doubt anything even uses the nvram
11:04:34 <Shockk> I'm looking for advice on strchr
11:05:03 <Shockk> the latest C and POSIX standards both define it as: char * strchr(const char *, int);
11:05:44 <Shockk> but if I try and implement it like this, I of course get a warning that I'm discarding const, which is true, but I don't see how else I'm meant to implement it without literally copying the string or something
11:06:19 <bcos_> ?
11:07:03 <Shockk> both C and POSIX define it as taking a const char* but returning a char*
11:07:22 <Shockk> I don't see how this is possible without discarding the const qualifier, but I don't know if this is a good or bad idea
11:07:50 <bcos_> "while( (*pointer != 0) && (*pointer != value) ) { pointer++; } return pointer;"
11:08:44 <Shockk> :/
11:08:57 <Shockk> this discards the const qualifier
11:09:02 <graphitemaster> yes, it has to
11:09:12 <Shockk> hmm okay
11:09:22 <graphitemaster> lots of those C style string functions discard const because C didn't have const when they were created and there's no function overloading in C
11:09:33 <Shockk> ah I see
11:09:36 <graphitemaster> in C++ strchr is overloaded to preserve constness though
11:09:42 <bcos_> D'oh - I was thinking "char const *"
11:09:43 <graphitemaster> if you use <cstring> instead of <string.h> that is
11:09:53 <Shockk> right I noticed that in C++
11:10:07 <graphitemaster> there's a similar thing with memcpy too
11:10:10 <Shockk> hmm so I should just ignore the warning I guess; is there a way to shut gcc up about it?
11:10:30 <graphitemaster> cast away the const
11:10:44 <Shockk> oh, explicitly
11:10:47 <Shockk> I'll try
11:10:53 <bcos_> Does pretending it's an array shut it up?
11:11:56 <graphitemaster> so memchr, strchr, strpbrk, strrchr, and strstr all have this problem, as well as bsearch
11:12:14 <Shockk> hm right
11:12:29 <Shockk> explicitly casting it did shut it up
11:12:31 <Shockk> great
11:12:37 <Shockk> thanks
11:12:40 <graphitemaster> it would've been smarter for these functions to return an offset in type size_t rather than a pointer
11:13:01 <graphitemaster> then it's the caller's responsibility to apply the offset and the constness would preserve
11:13:04 <Shockk> lots of things would have been smarter but oh well
11:13:49 <graphitemaster> they could've returned const char I guess, but then the caller would have to do the cast which would've been uglier
11:14:01 <graphitemaster> better to do it in the function, throw the const away and just remind the programmer to be careful
11:15:38 <bcos_> I think the spec got it wrong - "const char *" is purely retarded given that it's passed by value, and you do want the data it points to be const but it's not
11:16:49 <graphitemaster> bcos_, then you have to cast away const when calling the function for const data
11:17:07 <graphitemaster> lots of people use the functions to test for the existence of something in const strings, not necessarily to modify the contents
11:17:10 <bcos_> And? Look at those functions and tell me which one you'd expect to modify the data
11:17:18 <graphitemaster> like if (strstr(string, "thing")) { contains_thing(); }
11:17:23 <bcos_> Wait...
11:17:46 <bcos_> Maybe the spec is right and I was right initially and you're both idiots
11:17:56 <graphitemaster> remember that adding const is implicit, removing it is explicit, so something that takes const char* can be given something that is char*
11:18:07 <graphitemaster> but not the other way around
11:18:27 <bcos_> See https://stackoverflow.com/questions/10091825/constant-pointer-vs-pointer-on-a-constant-value
11:18:29 <bslsk05> stackoverflow.com: c - constant pointer vs pointer on a constant value - Stack Overflow
11:18:55 <graphitemaster> const on the pointer would be pointless
11:19:01 <graphitemaster> that would be like defining a function to take a "const int"
11:19:14 <graphitemaster> it just means in the local context of the function the pointer itself could not change
11:19:29 <graphitemaster> which isn't helpful
11:19:52 <graphitemaster> const char* on the other hand means that the data pointed to by the pointer cannot be changed, so when a function has that you know that it does not modify your passed in data
11:19:56 <bcos_> " char * strchr(const char *, int);" = the pointer is not const but the data it points to is (which is sane); and " char * strchr(char * const, int);" = stupid
11:20:07 <graphitemaster> yeah the latter is stupid
11:20:14 <bcos_> So..
11:20:17 <bcos_> "while( (*pointer != 0) && (*pointer != value) ) { pointer++; } return pointer;"
11:20:27 <graphitemaster> no you'd need return (char *)pointer
11:20:31 <bcos_> ^ except that's probably wrong for the "value not found" case
11:20:33 <graphitemaster> the point is that the const is lost on the return
11:20:43 <Shockk> yep it needs to return NULL if not found
11:20:45 <graphitemaster> your code would not compile without the explicit cast
11:20:59 <bcos_> Ah - I see now
11:21:06 <bcos_> "while( (*pointer != 0) && (*pointer != value) ) { pointer++; } return (char *)pointer;"
11:21:16 <graphitemaster> right, except now you can write dangerous code like
11:21:28 <Shockk> I did it as: for(size_t i = 0; s[i] != '\0';; ++i) { if(s[i] == c) { return (char *)&s[i]; } } return NULL;
11:21:28 <graphitemaster> const char a[] = "hello"; char *x = strchr(a, 'l'); *x = '\0';
11:21:38 <graphitemaster> oops you just trampled const data
11:22:07 <bcos_> But you can write "char a[] = "hello"; char *x = strchr(a, 'l'); *x = '\0';"
11:22:14 <graphitemaster> yes, which is fine
11:22:36 <graphitemaster> the point is because the const is casted away by the function internally, it's possible to get a non-const from a const and accidentally modify it and it will compile
11:23:13 <bcos_> You can write "char a[] = "hello"; char *x = (const char *)strchr(a, 'l'); *x = '\0';"
11:23:18 <bcos_> :-)
11:23:25 <graphitemaster> no that would fail to compile
11:23:41 <graphitemaster> You can write "char a[] = "hello"; const char *x = (const char *)strchr(a, 'l');"
11:23:42 <bcos_> You can't convert non-const to const?
11:23:51 <Maka_Albarn> does GRUB load ebx with the boot info in the same order that you request it?
11:23:53 <graphitemaster> the problem is the assignment is to a char*
11:24:03 <graphitemaster> you can't go const to non-const
11:24:07 <graphitemaster> you can go non-const to const
11:24:07 <Shockk> you wrote char *x = (const char *)..etc
11:24:16 <zid> ebx holds precisely one value, Maka_Albarn
11:24:21 <Shockk> that assignment would remove the const you just added
11:24:34 <bcos_> zid: EBX holds 32 different (one bit) values!
11:24:41 <zid> bcos_: I SAID PRECISELY
11:24:49 <graphitemaster> to this day it still doesn't surprise me people find pointers and constness confusing
11:24:58 <graphitemaster> even a seasoned programmer with 25 years of experience gets it wrong sometimes
11:25:06 <zid> bcos_: YOu can go non-const to const automatically, but only if absolutely NO pointers are involved at any step :P
11:25:43 * bcos_ mostly doesn't bother with const at all - it's like a safety device that's more hassle than having accidents
11:25:45 <Shockk> uugh I'm going to have to write `stat` now :(
11:25:53 <zid> const is broken as fuck
11:26:01 <zid> It's definitely not worth using
11:26:15 <Shockk> const is a lot nicer in C++ in my opinion
11:26:16 <graphitemaster> if you form a const pointer off an object then form another non-const pointer off the const-pointer (casting it away) it's not legal to compare the pointers for equality either, the standard does not require pointers of different types to the same object compare equal
11:26:25 <zid> I'm all for tagging stuff to help the compiler out, but const is horrifically unusable
11:26:27 <Shockk> except somewhat overloaded
11:26:38 <graphitemaster> so e.g const char a[] = "hello"; const char *x = a; char *y = (char *)a; x == y; // UB
11:27:59 <zid> Shockk: It's horrifically broken in C++ too
11:28:06 <Shockk> hmm
11:28:08 <Shockk> broken how?
11:28:12 <graphitemaster> I throw const all over the place in C++ where I can because it helps code generation, especially for member functions in C++ where if you don't specify const cv-q on the function body, the compiler may assume you're modifying contents of `this` so it will generate constant loads and spills to the data given by the class instead of assuming they don't change / alias
11:28:34 <zid> https://yosefk.com/c++fqa/const.html#fqa-18.1
11:28:35 <bslsk05> yosefk.com: C++ FQA Lite: Const correctness
11:28:49 <graphitemaster> if you go and remove all the const cv-q on std::vector for instance, most C++ software becomes about 12x slower
11:30:26 <graphitemaster> assuming it compiles
11:30:34 <graphitemaster> Rust's approach is much better to constness
11:30:44 <graphitemaster> everything is immutable by default
11:30:59 <graphitemaster> so a pointer to an object is basically "const T *const name" by default
11:31:15 <graphitemaster> and if you want mutable you use the mut keyword, and you can use it on the data pointed to and the pointer like in C++
11:31:17 <Shockk> zid: hm, I mean, const not affecting the data pointed by by the pointers, for a vector of pointers, just sounds like expected behaviour
11:31:20 <zid> That's the difference between Rust and C in general
11:31:37 <zid> C expects you to be doing real work, rust expects you to be doing nothing of value :p
11:31:57 <Shockk> for vector<T*> vs vector<const T*> it's more an issue of the way templates work and the type system works in general
11:32:07 <Shockk> there's work being done on this for C++20 I believe though
11:32:09 <zid> const is party of the type system, Shockk
11:32:21 <zid> "The problem with const is the type system", erm, no shit?
11:33:11 <Shockk> I was saying it's more related to how templates work
11:33:22 <Shockk> it affects more than const, it affects other things too
11:33:27 <graphitemaster> Rust has much smarter value semantics and optimizations around value semantics and wants you to avoid thinking in terms of data representation and memory layout and focus more on realizing this is just a contiguous arrangement of elements of specific type, it doesn't even mind if you pass big heaps of data by copy because it has smart move semantics too like C++'s std::move in a way but far more clever because it sticts to a strict
11:33:27 <graphitemaster> (only one owner of data at any given time)
11:33:54 <zid> irc does not work this way, graphitemaster
11:34:13 <graphitemaster> ?
11:34:24 <Shockk> right now it's possible to write a function that will take a vector of pointers to T but also works with whatever qualifiers are on it and stuff, but it's extremely messy
11:34:30 <zid> it has line limits
11:34:37 <graphitemaster> no it doesn't
11:34:39 <Shockk> concepts in C++20 will make it a lot easier
11:34:57 <zid> alright, continue thinking it doesn't
11:35:00 <graphitemaster> that vector<T*> vs vector<const T*> thing was solved a long time ago
11:35:04 <zid> and we just won't be able to read your messages
11:35:08 <graphitemaster> most of the FQA thing is just wrong
11:35:17 <Shockk> graphitemaster: oh what?
11:35:39 <graphitemaster> type qualifiers are part of the type
11:36:07 <graphitemaster> always have been, the ugly parts are how the standard works around that limitation to make interfaces that don't suck
11:36:30 <graphitemaster> largely has to do with why type_traits exist and stuff like remove_cv and remove_const and all that are riddled all over the place in standard containers
11:36:33 <Shockk> ah, I mean that's what I was referring to by "but it's extremely messy"
11:37:06 <graphitemaster> right it's extremely messy to support and implement correctly but you can provide safe non-messy interfaces with a lot of manual machinery through the use of templates
11:37:16 <Shockk> someone at my work did a talk recently about how concepts and a bunch of other related things are going to make it a lot cleaner and avoid code duplication
11:37:52 <Shockk> concepts seem pretty cool
11:38:23 <Shockk> seems somewhat like a typeclass in Haskell but different
11:39:02 <zid> "This is about the const keyword, which makes you write your program twice (or more, depending on your luck). "
11:39:10 <zid> "This fqa is so wrong, you just template it both ways"
11:39:14 <zid> lol.
11:39:38 <graphitemaster> yeah the whole fqa is written by someone who doesn't fully understand C++
11:39:45 <zid> point something out
11:40:11 <graphitemaster> a lot of this would've been better asked as questions on stack overflow where language lawyers could provide sensible answers to the questions
11:40:12 <zid> I don't actually know C++ so I can't argue semantics of how C++ works, but maybe I can point out something you misread or something idk
11:40:28 <zid> what do you mean, better asked as questions on stack overflow?
11:40:37 <zid> this page isn't a question
11:40:43 <klange> OBJECTION!
11:41:09 * john_cephalopoda throws a boot at klange's head
11:41:25 <graphitemaster> well usually when you get stuck in a language or can't find a way to express something, instead of writing how the language is broken and sucks and the problem with some language feature or machinery is it doesn't do the thing you want it to do, you ask people who are professionals first and get the right answer
11:41:35 <zid> what
11:41:39 <zid> the fuck
11:41:51 <zid> what 'answer'
11:41:55 <zid> what professionals
11:42:04 <zid> I have absolutely NO idea what you're talking about
11:43:12 <graphitemaster> people who understand the language well enough to know that everything in that fqa is trite
11:43:18 <graphitemaster> those would be professionals
11:43:25 <zid> what does that have to do with anything
11:43:26 <zid> at all
11:43:39 <graphitemaster> every single problem with the language outlined in that fqa can be expressed as a question rather than an attack on the language
11:43:44 <zid> what
11:43:46 <zid> the fuck
11:44:01 <zid> "Every single problem with C++ can be expressed as a banana sculpture"
11:44:12 <zid> no shit, why the fuck are you saying something so insane though
11:44:46 <graphitemaster> because the fqa is actually retarded, it's about as useful of a resource about C++'s short comings as an beginner asking questions that make no sense on stack overflow or IRC
11:44:52 <Shockk> hm
11:45:01 <zid> Shockk: Can you make any fucking sense of this?
11:45:08 <Shockk> maybe to point out an example, as this seems to be going nowhere
11:45:25 <Shockk> the fqa basically makes out that references are basically the same as pointers
11:45:26 <graphitemaster> well the whole const thing in that fqa for instance is 100% wrong
11:45:33 <zid> "Things can be expressed in other terms" "For example, a totally unrelated thing"
11:45:45 <Shockk> but it doesn't give any info about the number of differences between the two, and the situations in which references are safer to use than pointers
11:46:07 <zid> 'the whole const thing' doesn't even make sense
11:46:23 <graphitemaster> are you stupid?
11:46:36 <graphitemaster> it seems like you're incapable of understanding what I'm saying
11:46:39 <zid> yes
11:46:40 <zid> I am
11:46:45 <zid> THat's precisely what you've been saying for the past 10 minutes
11:46:51 <zid> err, I've*
11:47:08 <zid> but you keep ignoring it and just start making up even *more* bizzare sentences that don't make any sense
11:47:09 <Shockk> I think what graphitemaster is maybe thinking and trying to say, is, the gripes in that FQA seem valid on the surface, but what they refer to is actually only a shallow understanding of the part of the language they're referring to, just like with the references vs pointers thing I pointed out
11:47:31 <Shockk> I didn't read it all so idk
11:47:34 <zid> Shockk: Right, but what he actually said though, is that it would be better off if this document were an interpretive dance.
11:47:40 <graphitemaster> they don't even seem valid on the surface, they're mostly wrong
11:47:58 <zid> "things can be expressed in other ways" is literally the only thing he's actually said
11:48:06 <zid> everything else has just been a collection of words in random orders
11:48:13 <Shockk> graphitemaster: I more mean, they would seem valid to someone without more in-depth of that aspect of the language, I guess
11:49:04 <graphitemaster> they're wrong because the author who wrote this isn't looking at the full picture of the language and it's evident they didn't ask someone with more experience with the language questions
11:49:31 <graphitemaster> it's what I would expect someone who just picks a language up, gets upset and writes a bunch of nonsense about why they don't like it because they don't understand it would do
11:49:32 <zid> Shockk: Except he's 100% failed to produce any line of this huge page that is not correct, on any level, typo, grammar, semantics, syntax, whatever, and infact has misrepresented what's in it several times, suggesting he hasn't even actually even clicked the link, so idk
11:49:55 <bcos_> For C++; I'm fairly sure that the full picture of the language is "the language is so fucked that you're going to need FAQs to get const right and then the FAQs might even be wrong!"
11:49:57 <zid> and then gone on a rant about sculptures made of toothpicks being a better way to convey dissent
11:50:07 <zid> bcos_: yep, which is preciselyw hat this document says
11:50:27 <zid> infact, it's what the entire website is about
11:51:10 <graphitemaster> the problem are people are idiots and don't want to learn it correctly, they want to stick with their relatively simple model of it instead of fully groking the complexity
11:51:33 <zid> Okay at least I figured out what class graphitemaster belongs to, I've met a few of them
11:52:01 <graphitemaster> it's a part of the language and you're going to use it every day, learn it
11:52:14 <zid> People who invest themselves into into C++, waste years dealing with its horrific design, and come out the other end like a battered wife, "He only hits me because I make him angry" etc, completely unwilling to concede that they wasted their life.
11:52:20 <zid> Because, who'd want to do that, right?
11:53:16 <Shockk> I didn't really want to get involved in this but I feel it's necessary for someone to say this
11:53:16 <graphitemaster> all the problems C++ has with const, a language like Rust has too, it's just Rust chose the immutable by default design so you save a little typing because it turns out most programs don't need all their stuff to be mutable by default
11:53:22 <zid> s/do/admit to
11:53:44 <Shockk> zid I respect your opinion on whatever this is, but you're kind of being rude towards graphitemaster over *his* opinion
11:54:04 <Shockk> that's all I wanted to say
11:54:18 <zid> Shockk: Except.. he refuses to say what it is
11:54:27 <zid> And is just biblethumping about how great C++ is
11:54:41 <zid> I asked him specifically to pull even just one line from the document and show me it
11:54:49 <zid> i got 40 pages of complete non-sequtiors, and I called him on it
11:54:54 <zid> I'm not the one being 'rude'
11:55:11 <graphitemaster> I don't see what the problem is, you have three const's, you can have const on a data type which prevents modifying the contents of it, you can have const on a pointer (which prevents changing the pointer but not the data, or reference in this case if you want, though in C++ a reference cannot be reseated so it doesn't really make sense, it's redundant) and you have const cv-q on a method body which makes the "this" pointer for your
11:55:12 <graphitemaster> function const in that context (thus you cna't modify the contents of the structure/class in it)
11:55:13 <Shockk> I'll swiftly exit(1) here
11:55:16 <graphitemaster> it's not any more complicated than that
11:55:46 <zid> yes, we know how const works, graphitemaster. THe fact you can't "see the problem" is because you've ignored every single implementation detail.
11:55:59 <graphitemaster> there is no problem with this
11:56:28 <graphitemaster> that is something someone learning about const could understand in 1 minute after reading that sentence
11:56:34 <zid> You're right, there is no problem that you can't see them problem
11:56:39 <graphitemaster> there is no problem
11:56:50 <zid> So you're denying that there is any deficiencies in any part of C++?
11:57:16 <zid> (Or is it just const you're saying is flawlessly designed?)
11:57:18 <graphitemaster> C++ has a lot of deficiencies but a const ain't one of 'em
11:57:25 <zid> Okay so just the latter
11:57:40 <zid> You then proceded to say that the fqa is completely wrong, and refused to provide a single example
11:58:04 <zid> so you can see why I think you're an absolute moron, I'd hope
11:58:16 <graphitemaster> you could argue mutable by default is a deficiency I guess but if you understand that C is meant to be compatible in C++ and that choice is one of the reasons for its success and part of the design, it's not fair
11:58:50 <graphitemaster> lots of idiots think being compatible with C is a deficiency but I disagree