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=osdev2&y=22&m=5&d=26
00:00:00 <moon-child> (same name, but still separate slots)
00:00:00 <mrvn> or: class List { List & get_next(); }; class Derived : List { Derived & get_next(); };
00:01:00 <moon-child> in that case you have a different kind of problem
00:02:00 <moon-child> Derived *x, *y; x->insert(y); assert(some_cast<List>(x)->next == some_cast<List>(y))
00:02:00 <moon-child> is a desirable property, I would think
00:02:00 <mrvn> Or template <typename T> class List { T *next; }; class Derived : List<Derived> { }
00:03:00 <moon-child> that seems like a much more sensible arrangement
00:04:00 <mrvn> Wait, that actually compiled. Since when can I use the incomplete type as template parameter?
00:04:00 <moon-child> (except for that you can only be compile-time polymorphic over the type of your list elements. But I guess c++ does not have real polymorphism anyway so eh)
00:05:00 <mrvn> yeah, big drawback in C++. If the compiler/linker wouldn't merge identical template instances the code size would explode.
00:05:00 <moon-child> mrvn: same reason in c I can write struct list { struct list *next; ... }?
00:05:00 <moon-child> since you are only declaring a pointer, incomplete type is ok
00:05:00 <mrvn> <source>:2:16: error: 'List<T>::next' has incomplete type 2 | class List { T next; };
00:05:00 <moon-child> I would guess. Not knowing c++; there may be additional subtleties
00:05:00 <mrvn> only works for pointers
00:06:00 <moon-child> well, yeah. I can't say struct list { struct list next; ... } either
00:06:00 <moon-child> if I could, then 'struct list' would have infinite size
00:06:00 <mrvn> calling some method on T would fail too I think.
00:07:00 <moon-child> (except for the degenerate case when there is nothing else, but in that case the whole thing is useless so eh)
00:07:00 <mrvn> hmm, no. calling methods works too.
00:08:00 <mrvn> member pointers as template arguments doesn't work.
00:08:00 <mrvn> can't calculate the offset for an incomplete type.
04:08:00 <klys> so I got interested in using mmap() with MAP_32BIT to allocate a chunk of ram and execute a program within that chunk. as I understand it, I may need a VDSO in order to do that.
04:09:00 <klys> as the program would be running within a 64bit framework, I'm not sure how to interface with the linux kernel from within there
04:12:00 <klys> safe assumption is I have 32bit code to run and would like to interface with the rest of the program (outside mmap()) which uses 64bit syscalls. this question however relates to 32bit syscalls.
04:24:00 <klys> here's some example code that claims to access a vdso, though I'm not sure it will work with my mmap(): https://gist.github.com/croepha/e7f5142006c8510df7b6f7763557b7d7
04:24:00 <bslsk05> gist.github.com: Example of calling into the kernel vdso directly · GitHub
05:14:00 <klys> I've been reading code and the answer to my question is probably no, given that kaslr returns a 64-bit value as the vdso address to the parent process.
05:15:00 <klys> so, you can't have 32-bit vdso if you just mmap() and call 32-bit code.
05:32:00 <geist> word
05:33:00 <klys> :)
05:34:00 <geist> well, dword actually
05:34:00 <klys> in related news, you can get those numbers in $ cat /proc/self/auxv | xxd -ps
05:36:00 <klys> or even try $ LD_SHOW_AUXV=1 cat /proc/self/auxv | xxd
05:40:00 <klys> someone suggested doing an lcall with a 64bit segment descriptor here: https://lore.kernel.org/linux-mm/35a16a2c-c799-fe0c-2689-bf105b508663@virtuozzo.com/
05:40:00 <bslsk05> lore.kernel.org: Re: [PATCHv6 4/5] x86/mm: check in_compat_syscall() instead TIF_ADDR32 for mmap(MAP_32BIT) - Dmitry Safonov
05:41:00 <klys> still trying to wrap around that idea
06:04:00 <klys> here's what calls kaslr: https://elixir.bootlin.com/linux/v5.18/source/fs/binfmt_elf.c#L1019 get_random_long() will return 64bits.
06:04:00 <bslsk05> elixir.bootlin.com: binfmt_elf.c - fs/binfmt_elf.c - Linux source code (v5.18) - Bootlin
06:07:00 <klys> and here's some code that passes that value along: https://elixir.bootlin.com/linux/v5.18/source/arch/x86/entry/vdso/vma.c#L394
06:07:00 <bslsk05> elixir.bootlin.com: vma.c - arch/x86/entry/vdso/vma.c - Linux source code (v5.18) - Bootlin
06:14:00 <klys> taking a closer look at the output of the above cat|xxd command on 32bit and 64bit linux, it produces a 32bit value for .AT_SYSINFO_EHDR
06:14:00 <klys> in both cases
06:17:00 <klys> scratch that
06:22:00 * AmyMalik dies
10:26:00 <dostoyevsky2> What kind of OS is AWS?
10:27:00 <GeDaMo> Is AWS not based on some VM system?
10:27:00 <dostoyevsky2> you mean, like lambda?
10:28:00 <GeDaMo> I don't know what Lambda is in this context
10:29:00 <dostoyevsky2> I guess the standard one if KVM
10:29:00 <GeDaMo> Yeah, that's the sort of thing I was thinking of
10:30:00 <dostoyevsky2> lambda uses an application kernel like firecracker or gvisor
10:31:00 <j`ey> firecracker uses kvm
10:36:00 <dostoyevsky2> But cloud providers seem like a distributed OS.. where you can allocate CPUs/hardware and store your data in distributed consensus stores for queues/object storage/databases
10:49:00 <jafarlihi> Hey. I've got this OS: https://github.com/jafarlihi/HikmatOS/ . The issue is when I do fork() I need to init_irq() again because interrupts stop working. Any idea why would fork cause this?
10:53:00 <Mutabah> You forgot to `sti` or (or pop flags with IF set) in the new context
10:54:00 <jafarlihi> Mutabah: Doesn't `sti` alter the flags? Is pop required?
10:55:00 <Mutabah> It does, which is why it was a "or"
10:55:00 <j`ey> isnt that https://github.com/jafarlihi/HikmatOS/blob/master/kernel/kernel/task.c#L124 Mutabah ?
10:55:00 <bslsk05> github.com: HikmatOS/task.c at master · jafarlihi/HikmatOS · GitHub
11:23:00 <jafarlihi> I tracked it down to `irq_remap`, running it in forked process fixes the issue. No idea why, any ideas?
13:32:00 <Mutabah> j`ey: I was guessing
13:32:00 <Mutabah> probably should have said that
13:43:00 <mrvn> klys: Look at x86_32
13:53:00 <theseb> What do people think of Fuchsia OS? If I was a budding kernel hacker it seems that would be the most promising to study. Downside....C++ instead of C. However microkernel and security primitives seem elegant
13:54:00 <mrvn> upside: C++ instead of C.
13:56:00 <theseb> bah humbug
13:57:00 <theseb> mrvn: what about Go? Is that good for an os?
13:58:00 <mrvn> never used go. Rust is popular outside of C/C++.
13:58:00 <mrvn> ocaml (look up mirage) is good too
13:59:00 <theseb> mrvn: yea...Rust would have likely been good....but ffs...c++? srsly?
13:59:00 <mrvn> It has a safer typesystem than C, namespaces, RAII, ... Just leave out RTTI and exceptrions.
14:00:00 <theseb> mrvn: yes....i've heard of that strategy...if you can somehow enforce a good *subset* of C++ you might have a decent language
14:00:00 <theseb> mrvn: hopefully google is doing this for Fuchsia
14:00:00 <mrvn> and that's exactly what everyone does when using C++.
14:01:00 <theseb> mrvn: really? that's great to hear...i have new hopes for C++ then
14:01:00 <theseb> mrvn: however, i imagine very new software shop has a *different* subset they believe in so you end of having to learn all of C++ anyways?
14:01:00 <mrvn> RTTI and exceptions need extra (and a bit complex) work to setup. So when you start your kernel basically everyone just disables them.
14:02:00 <theseb> every*
14:02:00 <mrvn> Also you don't have the STL in freestanding mode. So that cuts down a lot too.
14:05:00 <theseb> yea i have no desire in learning stl
14:05:00 <theseb> mrvn: what is freestanding mode?
14:06:00 <sbalmos> no userspace lib
14:06:00 <mrvn> theseb: same as freestanding in C. Removes the userspace libs and only gives you the core language features.
14:07:00 <theseb> interesting
14:07:00 <mrvn> no memcpy(), strcat(), or in C++ no STL
14:07:00 <mrvn> freestanding is the core languzage that you can expect to work everywhere, especially naked hardware.
14:08:00 <mrvn> i.e. your good subset (except you reduce that even further by removing RTTI and exceptions usually)
14:10:00 <theseb> mrvn: i think you just made me a C++ fan
14:10:00 <sbalmos> you'll have to write some additional boilerplate ASM code to execute any static initializers before jumping into your C++ kmain, and you'll have to provide impls for new, delete, and I'm trying to remember what other?
14:10:00 <theseb> err a "C++ subset" fan
14:11:00 <mrvn> You probably want the initializers for C too anyway. As for new/delete. If you need them the compiler will tell you.
14:11:00 <jafarlihi> How do you store the actual location (file bytes) of inode in the backing device?
14:11:00 <mrvn> what's an inode?
14:12:00 <jafarlihi> It stores name and other crap
14:12:00 <jafarlihi> What about actual location?
14:12:00 <Mutabah> inode locations are specified by the specific FS's spec.
14:13:00 <jafarlihi> So in FS impl you have a map of inodes to actual locations?
14:13:00 <mrvn> jafarlihi: or not
14:13:00 <Mutabah> a map, or a mapping equation
14:13:00 <mrvn> bttrfs just uses the address as inode number.
14:14:00 <Mutabah> ext2+ have inode number be indexes into a fragmented table
14:14:00 <mrvn> ext4 has inode tables and the inode number is the index in the table.
14:14:00 <mrvn> tables have the problems that they might become full.
14:15:00 <jafarlihi> How do you assign unique inode numbers?
14:15:00 <Mutabah> FAT doesn't have "inodes", so it's up to your driver how it makes inode numbers
14:15:00 <mrvn> by knowning what's free
14:16:00 <mrvn> FYI: inode numbers aren't unique. FSes usualy also have a generation number in the inode so they can make them unique even when reused.
14:18:00 <sham1> That sounds pretty unique to me
14:21:00 <zid> return 7l
14:21:00 <zid> s/l/;
14:21:00 <zid> That's unique at *least* once
14:21:00 <sham1> return 4; // Randomly selected
14:22:00 <jafarlihi> For directory inode, how do you store the list of children? Just a list in inode structure?
14:23:00 <sham1> Anyhow, reuse via a generation number could easily be seen as creating a unique "inode" even if that's technically not what happens
14:23:00 <sham1> jafarlihi: yeah, (at least on ext2+) the directory inode points to blocks which contains a bunch of "directory entry" records
14:27:00 <mrvn> jafarlihi: a directory is just a file
14:27:00 <mrvn> formate specified by the FS
14:29:00 <sham1> In fact, in the Good Old Days^{TM}, you could even open(2) a directory and access its files that way
14:30:00 <sham1> That's even seen in the UNIX Programming Environment-book by Kernighan and Pike
14:41:00 <mrvn> sham1: It's fun writing your own "ls" by opening the dir and interpreting the data.
14:42:00 <mrvn> I think it no longer works with tree based filesystems. Since they don't exactly store directories as files anymore.
14:42:00 <mrvn> all the COW filesystems
16:09:00 <jafarlihi> What data structure would you use for keeping pointers to child inodes in the parent directory inode?
16:09:00 <mrvn> BTree
16:10:00 <mrvn> Hashtbl
16:10:00 <mrvn> depending on whether directories are files (Hashtbkl) or not (Btree)
16:11:00 <jafarlihi> How do you use hashtbl? Filename as index and inode pointer as value?
16:11:00 <mrvn> yes, that' how ext3 does it
16:11:00 <jafarlihi> cool, thanks
16:12:00 <mrvn> You also need to store the filename in the directory.
16:13:00 <mrvn> so actually you have hash(name) as key and {offset of name, inode} as value.
16:13:00 <mrvn> or the hash table just points to buckets and buckets have dynamic size to contain the name.
16:14:00 <jafarlihi> I think I'll just use a linked list
16:15:00 <mrvn> jafarlihi: decades of experience have shown that to be horribly slow. But it's what they used to do because it's so simple.
16:15:00 <jafarlihi> Not worrying about speed yet
16:15:00 <mrvn> s/linked list/buffer containing direntires of variable size and you have to parse through all of them to find the right entry/
16:16:00 <mrvn> jafarlihi: are you talking about the in-memory representation or the on-disk format?
16:16:00 <jafarlihi> in-memory
16:17:00 <mrvn> don't you have a std::map<name, inode*> equivalent?
16:18:00 <jafarlihi> No
16:19:00 <mrvn> then maybe take a break and implement a set of standard containers. List, array, vector, hashtbl, set, map.
16:23:00 <sham1> rb-trees
16:23:00 <sbalmos> bah, just implement a ring buffer. unlimited capacity
16:24:00 <sham1> Unlimited capacity!*
16:24:00 <sham1> *: Terms and conditions apply
16:24:00 <mrvn> sham1: not avl?
16:24:00 <mrvn> lets give him a challenge
16:25:00 <sbalmos> I haven't done an avl tree in 18 years. :/
16:25:00 <sham1> RB-trees are certainly easier at least for me personally than AVL
16:31:00 <sham1> Personally my biggest gripe is that there really aren't any good test cases online
16:31:00 <sham1> Like for verifying that an RB-tree is implemented correctly
16:45:00 <mrvn> sham1: you want a online site that gives you a unit test to implement against and then runs it?
16:46:00 <sham1> I mean, that's one way. I suppose I could also use an existing implementation to get a test vector
16:47:00 <mrvn> there is leetcode and similar sites that give you coding challanges.
16:47:00 <mrvn> basically the sam thing. Just change the assignments to be more generic
16:52:00 <mrvn> Is there a `realloc` that fails if it has to copy the data?
17:05:00 <j`ey> with objcopy -O binary.. does it keep the bss as a section full of zeros?
17:05:00 <mrvn> no, but any holes you have.
17:05:00 <mrvn> i.e. put .bss at the end
17:06:00 <j`ey> so if it's not at the end, it will keep it then?
17:06:00 <mrvn> anything NOALLOC will be skipped
17:06:00 <j`ey> because my binary seems quite big, feels like the bss is in there
17:07:00 <mrvn> j`ey: dump the symbol and check where _bss_start and _bss_end is.
17:07:00 <mrvn> _bss_start - _start should give you the filesize.
17:07:00 <j`ey> good idea
17:08:00 <j`ey> hmm somehow I think that my bss is overwriting the fdt, I just cant understand how/why
17:08:00 <zid> what are you giving it as an input?
17:09:00 <j`ey> giving what, objcopy?
17:09:00 <zid> yea
17:09:00 <j`ey> an elf
17:09:00 <zid> just the full input sections with no .j?
17:10:00 <j`ey> https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/blob/master/arm/Makefile.common#L71
17:10:00 <bslsk05> gitlab.com: arm/Makefile.common · master · kvm-unit-tests / KVM-Unit-Tests · GitLab
17:13:00 <jafarlihi> What does "opening" a file mean in VFS level (not fd)? Is it just no-op for ramfs?
17:13:00 <mrvn> increment the reference counter
17:14:00 <jafarlihi> Why do we even need a ref counter there?
17:14:00 <zid> fd isn't just for ref counting
17:14:00 <zid> it's so you can actually know what to do when read() etc happens more usually
17:15:00 <zid> unless you want to completely rewalk your devices and filesystems every time someone does read() it may be wise to cache that
17:15:00 <zid> plus the file position pointer
17:15:00 <mrvn> j`ey: because someone can unlink() the file while you have it open.
17:15:00 <zid> and you may end up doing things like needing to invalidate memory mappings for memory mapped files at close time etc, all that needs to be tracked so it can be undone
17:20:00 <mrvn> I see std::for_each but no std::fold_left. Isn't there a for_each where an accumulator gets passed along?
17:27:00 * geist yawns
17:27:00 <geist> good morning everyone
17:27:00 <jafarlihi> good morning
17:28:00 <jafarlihi> it's evening here
17:29:00 <geist> yay time zones
17:35:00 <jafarlihi> Can GitHub take down your repo if someone reports license violation (copy pasting from random projects)?
17:40:00 <sham1> mrvn: std::transform?
17:42:00 <sham1> Or std::reduce
17:42:00 <mrvn> sham1: no, std::accumulate. But that doesn't seem to have range support
17:42:00 <sham1> Although that is in <numeric>
17:42:00 <sham1> Ah
17:42:00 <sham1> Hm
17:42:00 <sham1> Eh, doesn't seem that bad to implement
17:43:00 <mrvn> wait, what's the difference between accumulate and reduce?
17:45:00 <GeDaMo> Apparently reduce can be out of order
17:45:00 <sham1> According to cppreference: "in other words, reduce behaves like std::accumulate except the elements of the range may be grouped and rearranged in arbitrary order"
17:45:00 <sham1> Yeah
17:46:00 <mrvn> yeah, seems to just add an execution_policy
18:03:00 <geist> oh yay, finally got a smoking gun on my ryzen crash: a 3900x in the same server motherboard as the 3950x that was failing also fails
18:04:00 <geist> so cpu is off the hook
18:04:00 <geist> more predictably it's probably the motherboard
18:11:00 <zid> moar volts
18:15:00 <chibill> I sort of want to try and write my own file system just for the fun of trying. (I still don't have my OS doing anything but Hello World. Since its more of a side project as I work on a homebrew computer system.
18:15:00 <chibill> * computer system.)
18:49:00 <geist> chibill: yeah i think it's pretty fun. the designing part is fun
19:54:00 <zid> Time for my yearly emerge --sync --break-everything-now
19:55:00 <zid> --python-especially
19:56:00 <sham1> Call it a hunch, but I think it's due to you doing it once a year
19:57:00 <sham1> Ye need to roll the release more often
20:00:00 <zid> how dare you
20:00:00 <psykose> it's much more fun to break everything once a year though
20:25:00 <Ermine> Breaking gentoo by updating once a year?
20:27:00 <mrvn> Ermine: well, it takes that long to compile, doesn't it. :)
20:30:00 <zid> 1 of 237, it doesn't have unresolvable blockers :o
20:39:00 <jafarlihi> Would you say doing OS development is harder than compiler development in general, or just about the same, or easier?
20:39:00 <mrvn> yes
20:45:00 <geist> probably easier
20:45:00 <geist> if nothing else because there's a lot of helpful material out there
20:45:00 <geist> ie, it's a very well trodden path, ad there's people like here that will talk about it and help you, etc
20:45:00 <geist> but then 'os development' is a very wide field, of huge varieties of complexity
20:45:00 <geist> though compiler as well
20:46:00 <zid> yea it's just wide
20:46:00 <sham1> I'd say that compilers is different kind of difficult
20:46:00 <zid> compiler once it 'works' is about increasingly complex things
20:46:00 <geist> yah
20:47:00 <sham1> Although I'd say that just doing a dumb compiler isn't *that* difficult, the difficulty comes in making it good. Now of course, same could be said about OSes, although OSDev has a lot more busywork to get all the devices to work and such
20:48:00 <geist> yeah, OTOH the busywork has i think in general a lot more resources available in the form of tutorials and emulators and whatnot
20:48:00 <sham1> Yeah, well, compilers have LLVM
20:48:00 <geist> so it's a tradeoff. but a lot of it also is how well acclimated you are or flexible abut working with low level stuff (bit twiddling, etc)
20:49:00 <geist> and some folks have toruble bridging that gap
20:50:00 <zid> they'd have even more trouble with a compiler then :P
20:51:00 <mrvn> Now write an OS that lets you input source and it compiles and executes it.
20:51:00 <zid> "I fucked up all the memory barriers in my osdev" -> "I had to write code to programatically deduce where barriers are necessary for my compiler"
20:51:00 <zid> the latter is a superset of difficulty of the former
20:52:00 <sham1> mrvn: I've actually thought about doing that unironically. Some kind of a modern Lisp machine
20:52:00 <geist> sure, but i mean you can generally rely on higher level language constructs you may be used to
20:52:00 <geist> whereas OS work you sometimes/frequently have to fight the language itself
20:52:00 <geist> or use a language you're not used to
20:53:00 <zid> That just makes the compiler even harder compared to the osdev
20:56:00 <mrvn> a lisp machine in lisp is realy simple.
20:57:00 <mrvn> zid: how about making up the language as you write the compiler?
20:57:00 <sbalmos> image-based runtime environment, like Smalltalk
21:36:00 <mrvn> Got to love C: 1[&i[array]]
21:55:00 <geist> i bet that's undefined now given gcc 12.1 and the null pointer nonsense
22:00:00 <mrvn> can't be. it's perfectly legal and at no point is a nullptr or literal converted to pointer involved.
22:00:00 <zid> I love how the most heavyweight part of updating a linux system is now rust not gcc
22:00:00 <zid> by a big margin too
22:00:00 <mrvn> zid: I though the biggest thing is open office and latex
22:09:00 <geist> mrvn: yea but as i've discovered, gcc 12 is really warn heavy about what appears to be any known derefs to anything < 4K
22:09:00 <geist> it only warns, though
22:09:00 <geist> feeding it through a global seems to 'fix' it though
22:10:00 <geist> https://github.com/littlekernel/lk/blob/master/platform/rosco-m68k/platform.c#L47 for example causes it not to freak out over it, since i think the globalness of that variable means it can't know for sure it wasn't mutated (despite it being const)
22:10:00 <bslsk05> github.com: lk/platform.c at master · littlekernel/lk · GitHub
22:11:00 <graphitemaster> (&array[i])[1] is definitely undefined behavior
22:12:00 <graphitemaster> The whole rules about array-types in general basically prevent any sort of stuff like that.
22:12:00 <mrvn> geist: It's not const: declare sdb as pointer to const volatile struct rosco_system_data_block
22:12:00 <geist> oh yeah. you're right, i was just thinking about that
22:12:00 <mrvn> Having a volatile const doesn't make much sense.
22:13:00 <mrvn> You have to read it but it must give you the same value every time?
22:13:00 <geist> indeed
22:13:00 <geist> anyway, it fixed the bug, otherwise if you just try to create a local pointer to something at 0x400 the compiler says it's a null pointer blahlbha
22:13:00 <geist> and i explored it tob e anything < 4K
22:13:00 <mrvn> cdecl> explain volatile struct rosco_system_data_block * const sdb;
22:13:00 <mrvn> declare sdb as const pointer to volatile struct rosco_system_data_block
22:14:00 <mrvn> Isn't that what you want?
22:14:00 <geist> yes yes i get it
22:14:00 <geist> yes
22:14:00 <geist> i thought that the moment i pasted it, like 'shit i think that's not the const i expected'
22:14:00 <mrvn> *jipey* I fixed my first bug in LK. :)
22:14:00 <geist> basically i kept adding shit until the problem went away
22:14:00 <geist> somehow adding the const i think fixed it
22:14:00 <geist> or the volatile
22:14:00 <geist> i dunno, i was just trying to get the compiler to quit warning at me about something that shouldnt have warned me
22:15:00 <mrvn> The lack of *const should fix it
22:16:00 <geist> what i was really trying to get it to do was not roll a variable that it then derefed, so what was even weirder is even though that variable isn't const, it actually compiled it out in the disasm
22:16:00 <geist> which is head scratching, since it should have assumed something external could mess with it
22:16:00 <mrvn> Does rosco have special protextion for the first 0x400 byte like Amigas have?
22:16:00 <geist> no
22:17:00 <geist> its just the firmeware having had tossed down some data structures < 8K
22:17:00 <geist> i was all else held equal going to treat it like a const thing since i had no intention of writing to it
22:18:00 <mrvn> is the firmware/hardware going to write to it?
22:18:00 <mrvn> I just realized that "const volatile" only means you can't write to it but it can still change.
22:20:00 <mrvn> C/C++ really lacks an immutable qualifier.
22:21:00 <geist> right. that's really my intention
22:21:00 <geist> ie, please read from this it might change, but i dont want to write to it
22:22:00 <geist> ow that i think about it more it's actually what i was trying to do
22:22:00 <geist> and i had to run it through a non const pointer because that fooled the compiler into not assuming it's a fixed variable
22:23:00 <mrvn> I really hope they fix that soon in gcc
22:24:00 <geist> you can of course just nerf the warning, but it *can* catch some good stuff
22:25:00 <geist> it's just that it gets hoovered up into this 'also try to catch null pointer' stuff
22:25:00 <geist> worse, it's optimization based. the compiler has to have sufficiently high optimization levels to try to see through the code enoguh. so -O0 wont see it
22:27:00 <mrvn> -O0 should just be removed. It never ever makes sense to use.
22:28:00 <geist> it's certainly not useful to me
22:31:00 <mrvn> Sometimes I want -O0 + register allocation.
22:32:00 <mrvn> or even just eliminate all pairs of "store to stack, read from stack"
23:10:00 <mrvn> Have you ever used a function-try-block? struct A { ~A() try { /* something */ } catch (const std::exception& e) { /* something */ if (no_terminate_on_exception) return; } };?
23:11:00 <mrvn> It's C11 but I've never seen it till today.
23:21:00 <heat> mrvn, i've done that yes
23:21:00 <heat> it's very nice
23:21:00 <mrvn> it's odd that it re-throws the exception on it's own.
23:22:00 <mrvn> (unless you return in the destructor)
23:22:00 <heat> it does?
23:22:00 <heat> fuck you just ruined the feature for me
23:23:00 <mrvn> >
23:23:00 <mrvn> Reaching the end of a catch clause for a function-try-block on a destructor also automatically rethrows the current exception as if by throw;, but a return statement is allowed.
23:23:00 <heat> oh, destructor
23:23:00 <mrvn> > Every catch-clause in the function-try-block for a constructor must terminate by throwing an exception. If the control reaches the end of such handler, the current exception is automatically rethrown as if by throw;. The return statement is not allowed in any catch clause of a constructor's function-try-block.
23:24:00 <mrvn> In the constructor what is the compiler supposed to do otherwise? The object you created has already been destroyed. What should happen if it just returns?
23:25:00 <heat> why has it been destroyed?
23:25:00 <mrvn> > Before any catch clauses of a function-try-block on a constructor are entered, all fully-constructed members and bases have already been destroyed.
23:25:00 <mrvn> The construction threw an exception, you don't have a valid object. So it gets destroyed.
23:28:00 <geist> yah the rules of exceptinos in constructors/destructors i never understood
23:29:00 <geist> but then, i dont think i've ever worked in a project that actually used c++ exceptions
23:32:00 <mrvn> Say I have struct A { A() try : x{}, y{} { } catch (const std::exception& e) {} X x; Y y; } and y{} throws an exception and the x::~X() throws an exception will that enter the catch block twice?
23:32:00 <mrvn> or not at all since ~X() terminates?
23:33:00 <mrvn> geist: You kind of can't use inheritance then for anything with error handling.
23:33:00 <heat> you can't do non-trivial work in constructors in noexcept code
23:34:00 <heat> that's pretty firmly banned in google C++
23:34:00 <mrvn> I kind of whish that constructors would `return *this;` like operators. Then `return nullptr` would signal an error.
23:34:00 <heat> that wouldn't work
23:34:00 <heat> they would have to 'return this;', not *this
23:34:00 <mrvn> `return this;` I mean
23:34:00 <heat> more inconsistency? no ty
23:35:00 <geist> there was some mention a whie back as to 'why is this a pointer and not a reference' which i thought was kinda intersting
23:35:00 <geist> the main reason is references hadn't been implemented yet
23:35:00 <mrvn> geist: historical, this was invented before references.
23:35:00 <geist> but actually would be interesting if this was a reference
23:36:00 <clever> my rough understanding is that `new` is just malloc + constructor
23:36:00 <mrvn> it is
23:36:00 <clever> so the memory would have already been allocated, and you would need to detect that error and then turn around and free it
23:36:00 <mrvn> as it does
23:36:00 <clever> what about just using exceptions?
23:36:00 <clever> have the constructor throw?
23:37:00 <clever> and the catch block will deal with free as it already does
23:37:00 <clever> and/or finnally
23:37:00 <mrvn> needs a bunch of extra runtime support
23:38:00 <clever> ive not actually looked into what that involves
23:38:00 <clever> does the osdev wiki say?
23:39:00 <mrvn> Me neither. I just saw the missing symbols when I forgot to disable exceptions.
23:39:00 <geist> not sure it needs that much else, maybe just some stuff effectively like pure virtual
23:39:00 <geist> where you need the falback thing
23:40:00 <heat> you need a function that allocates exception
23:40:00 <heat> __cxa_allocate_exception or whatever that's called
23:40:00 <heat> plus RTTI
23:40:00 <mrvn> The thing is that everywhere else you can use std::optional for example. But for constructors there is no other way but exceptions to fail.
23:40:00 <heat> and then the stuff that makes it walk the calling stack
23:40:00 <mrvn> stack unwinder
23:41:00 <heat> right
23:41:00 <heat> uga booga very late here
23:41:00 <mrvn> That part is probably the hardest
23:41:00 <heat> std::optional is a poor return type
23:41:00 <heat> I use andrei andreescu's expected<Type, ErrorType> quite a lot
23:41:00 <heat> it's a fancy optional
23:41:00 <mrvn> or std::variant
23:42:00 <heat> std::variant is non-trivial
23:42:00 <FireFly> sounds like an Either
23:42:00 <clever> mrvn: would libgcc provide the stack unwinder, or is it something you have to provide yourself?
23:42:00 <heat> clever, libgcc would
23:42:00 <clever> i feel like its gcc's responsibility, given that gcc is what manages the stack
23:42:00 <mrvn> clever: I would say gcc has to. It's winding up the stack.
23:42:00 <heat> wait hrm
23:42:00 <heat> that's libunwind
23:42:00 <heat> does gcc put libunwind into libgcc? i think so
23:43:00 <heat> https://github.com/heatd/Onyx/blob/master/kernel/include/onyx/expected.hpp
23:43:00 <bslsk05> github.com: Onyx/expected.hpp at master · heatd/Onyx · GitHub
23:43:00 <heat> this is very trivial, very simple C++
23:43:00 <heat> exactly my type of C++
23:44:00 <mrvn> FireFly: std::expected (C++23) is: a wrapper that contains either an expected or error value
23:44:00 <heat> that's in C++23?
23:44:00 <mrvn> https://en.cppreference.com/w/cpp/header/expected
23:44:00 <bslsk05> en.cppreference.com: Standard library header <expected> - cppreference.com
23:45:00 <mrvn> whatever the general utility library is I want it.
23:45:00 <heat> hey that's a good add
23:45:00 <heat> although I ultimately see a problem with it: it can throw
23:46:00 <heat> I guess that's not a problem as it can just std::terminate()?
23:46:00 <heat> (on noexcept throws)
23:46:00 <heat> still, weird consistency. this is only useful for noexcept code
23:46:00 <heat> is it just a "hey we can't lose this" from the exceptions fans in the committee?
23:47:00 <FireFly> ah, I don't speak C++
23:47:00 <mrvn> heat: I would expect code that returns an std::expected to be noexecpt
23:47:00 <heat> the C in C++ means cringe
23:47:00 <heat> mrvn, exactly
23:48:00 <geist> c++ is cringe, but even more so?
23:48:00 <psykose> the cringe was in us all along
23:48:00 <geist> everyone has a little bit of cringe
23:48:00 <heat> the C in C means "Can't take it anymore, where is the fucking memory leak, why am I programming in a 70s language"
23:48:00 <klange> The C in C++ means "cringe"
23:48:00 <mrvn> heat: I bet std::expected is noexcept if the construtors for it's contained types are noexcept.
23:49:00 <klange> so C++ means "ringe"
23:49:00 <heat> shut up klange, stop being ringe
23:49:00 <geist> cringe leads to anger
23:49:00 <geist> cringe leads to fear
23:49:00 <mrvn> eringe?
23:49:00 <mrvn> dringe?
23:50:00 <heat> mrvn with the top tier alphabetical skills
23:50:00 <heat> :P
23:50:00 <mrvn> it's 2am.
23:50:00 <heat> stop stealing my excuses
23:50:00 <mrvn> I've been up for 8 hours or so.
23:50:00 <psykose> that's too many hours
23:50:00 <geist> Ç®îñ©é
23:51:00 <psykose> crince
23:51:00 <klange> y'all should use a real language
23:51:00 <klange> ya know, one you built yourself out of toothpicks and chewing gum
23:52:00 <heat> reject languages
23:52:00 <heat> go back to caveman
23:54:00 * geist paints program on wall
23:54:00 <mrvn> I have camomile and caramel.
23:55:00 <mrvn> .oO(If only my compiler would produce binary already)
23:55:00 <klange> heat: we can do that https://esolangs.org/wiki/Ook!
23:55:00 <bslsk05> esolangs.org: Ook! - Esolang
23:56:00 <mrvn> I'm kind of stuck on the actual code generation for both my languages.
23:56:00 <mrvn> klange: Shouldn't Ook! refernece the Diskworld Novels?
23:57:00 <klange> *shrug*
23:59:00 <mrvn> https://codewithrockstar.com/
23:59:00 <bslsk05> codewithrockstar.com: rockstar : home