<sortie>
It's partially that I haven't migrated pub.sortix.org yet, but also there's the fast TCP issues that would slow down practical Sortix downloads for everyone, also combined with my worries that a stateful harddisk Sortix VM might not be reliable enough (which is why I'm testing on the ahti sortix)
<heat_>
gotta work on those
<heat_>
my tcp is still sometimes behaving weirdly and not quite as fast as i want it to
<sortie>
Plus that building Sortix requires pub.sortix.org to be online (to download the port tarballs, if not prepopulated) which creates a fun cyclic dependency where if I break Sortix nightly then Sortix's infrastructure might go offline and not come back online and break the ability to build a new fixed release
<heat_>
so im holding off on The Big Merge for now
<heat_>
actually i might've accidentally merged it yet, not sure
<sortie>
So I need a big rollback ability in case that stateful machine gets fucked, plus the ability to route the traffic back to Linux
<heat_>
ok no not merged, good
<sortie>
heat_: Otherwise yeah it's easy enough for me to serve a lot of static files with nginx and tls
<heat_>
anything that came before it was _much_ worse but it still needs work
<sortie>
You haven't merged Onyx networking?
<sortie>
What, are you, uh, me?
<heat_>
i have had onyx networking for a long time
<heat_>
_good_ TCP support is new
<heat_>
and it still isn't good enough for tha heat to be happy
<sortie>
But yeah uh finishing this tix stuff means the 1.1 stuff is starting to be quite near
<sortie>
Networked package management is definitely the biggest remaining task, then some more smooth sailing stuff after that
Dead_Bush_Sanpa1 has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpai has quit [Ping timeout: 265 seconds]
Dead_Bush_Sanpa1 is now known as Dead_Bush_Sanpai
Dead_Bush_Sanpa1 has joined #osdev
zu0 has joined #osdev
Dead_Bush_Sanpai has quit [Ping timeout: 265 seconds]
Dead_Bush_Sanpa1 is now known as Dead_Bush_Sanpai
<kof673>
> Is there an osdev archetype for people that build and document super complex package management tooling like this??
<kof673>
people may disagree, but generally i prefer cross-compiling whenever possible
jkra has joined #osdev
jkra has left #osdev [#osdev]
<kof673>
it means e.g. having 20 or however many toolchains on one system for all the osen, and then still fire up VMs to test binaries/etc. but a bit easier
housemate has joined #osdev
housemate has quit [Quit: Nothing to see here. I wasn't there. I take IRC seriously.]
housemate has joined #osdev
vdamewood has quit [Quit: Life beckons]
housemate has quit [Quit: Nothing to see here. I wasn't there. I take IRC seriously.]
heat_ has quit [Ping timeout: 264 seconds]
pog has quit [Quit: byee]
zu0 has quit [Ping timeout: 272 seconds]
qubasa has joined #osdev
dragestil has joined #osdev
dragestil has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
dragestil has joined #osdev
dragestil has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
hwpplayer1 has quit [Quit: I'll be back later See you people !]
netbsduser has joined #osdev
alexander has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
alexander has joined #osdev
goliath has joined #osdev
msv has quit [Remote host closed the connection]
npc has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
goliath has quit [Quit: SIGSEGV]
xenos1984 has joined #osdev
GeDaMo has joined #osdev
<netbsduser>
ring0_starr: maybe a few on 8086
<netbsduser>
actually CHERI is conceptually not dissimilar
<sortie>
kof673: Indeed, I like cross-compilation a lot too. Sortix has really, really pushed what's possible with cross-compilation and I can build 90 ports without issue, including a lot that doesn't cross-compile out of the box or easily.
<sortie>
It makes it much easier to use a fast operating system to build, and also to do all the architectures in a single build
<sortie>
And cross-compiling is really nice to know that you got a true bootstrap
<ring0_starr>
..lol. british college gets DARPA funding
ionut_f has quit [Remote host closed the connection]
<sortie>
https://gitlab.com/sortix/sortix/-/blob/master/build-aux/smoketest.sh ← See e.g. my smoketest.sh script that takes a fresh Sortix build, configures it to start ssh, then sshs in and runs some tests, and exits depending on whether the tests were successful. Basically the build + qemu testing that you mentioned. Plus, this even works recursively, Sortix runs in qemu and does this, spawning a nested qemu for testing.
<ring0_starr>
netbsduser: thanks, i have a bit of reading to do. this looks pretty much exactly like what i was trying to articulate.
vdamewood has joined #osdev
jedesa has joined #osdev
<nortti>
ring0_starr: intel iapx 432 (and also the segmented protected mode on 286 and later, if you use it like originally envisioned) has a CPU-level concept of "object" with bound checked accesses
vdamewood has quit [Quit: My Unrecognized Mac has gone to sleep. ZZZzzz…]
terrorjack4 has joined #osdev
ionut_f has joined #osdev
craigo has joined #osdev
ionut_f has quit [Remote host closed the connection]
edr has joined #osdev
heat has joined #osdev
<heat>
rust
CryptoDavid has joined #osdev
<nikolar>
crust
<sortie>
c++rust
msv has joined #osdev
<heat>
the best part about being a rust programmer is when you go off the deep end
<GeDaMo>
Does Rust even have a shallow end? :P
goliath has joined #osdev
jedesa has quit [Quit: jedesa]
goliath has quit [Client Quit]
goliath has joined #osdev
Dead_Bush_Sanpai has quit [Ping timeout: 252 seconds]
<nikolar>
does rust have an end
<heat>
you either die a rust hater or live long enough to become a type system formal verification borrow checker safety cargo crate enjoyer
<the_oz_>
implying that rust is that way rather than haskell or derivative
<the_oz_>
c'mon maaaan
npc has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
gog has joined #osdev
<mcrod>
hi
<mcrod>
haskell is cool
<heat>
shut up you're lame
<the_oz_>
type system theory is assuredly haskell
<the_oz_>
rust is just bot
<heat>
rust is haskell for genz
<the_oz_>
not*
<the_oz_>
rust is hardly even notC
<the_oz_>
it's so HR busybody types can feel good about having anything to say about code
<mcrod>
increasingly however, rust is being used in the Field (TM)
<mcrod>
even I've started to play around with it a little bit more
<mcrod>
it's the language that will not die
<the_oz_>
"I stopped submitting doc patches"
<netbsduser>
forget rust
<mcrod>
I still can't believe people are really using rust in the real world
<netbsduser>
i'm experimenting with C++ (which is a kind of SIMULA-like extension to the C programming language) to monomorphise pmap code for diverse page table geometries
<heat>
what's this C++ thing? i've never heard of it
<heat>
is it new?
<mcrod>
also
<mcrod>
as far as I know
<netbsduser>
the idea is to expose a set of entry points for various instantiations (for different pt geometries) of a single templated class, so that within that class, it doesn't need to load variables and check conditions everywhere
<mcrod>
rust forbids pointer aliasing, i.e., `restrict` keyword in C, just used fucking everywhere
<heat>
what?
<netbsduser>
this way i can deal with multiple basic page sizes, different pt geometry (e.g. risc-v sv39/48/57), etc
<mcrod>
what do you mean what
<netbsduser>
intra-arch i mean, inter-arch already is no problem
<heat>
restrict is not "pointer aliasing"
<mcrod>
i know that
<mcrod>
restrict _basically_ means "given two pointers, these two pointers do not point to the same memory location"
<heat>
also, do you know what languages also forbid pointer aliasing?
<heat>
C and C++
<mcrod>
what
<mcrod>
do we have the same definition of pointer aliasing in our brains
<heat>
int *a = 0x1000; short *b = 0x1000;
<netbsduser>
mcrod: the bilion-dollar mistake of the "standards committee"
<heat>
*a; *b; /* this is ub and might blow up your house */
emntn has joined #osdev
<mcrod>
right
<mcrod>
that's not at all what I was talking abuot
<mcrod>
about*
<the_oz_>
What is 'Why memcopy must start at the end going reverse' for 1000?
<heat>
memcpy doesn't start at the end
<heat>
memmove does, *sometimes*
<mcrod>
speaking better: in Rust, two mutable references cannot alias, so "restrict" is implied
<heat>
ok
<mcrod>
but in C and I *believe* C++, you have to explicitly use restrict/__restrict__ to get the same behavior
<heat>
netbsduser, i like my linuxpilled page table scheme
<mcrod>
and I'm saying this stuff because I'm seeing a bunch of crap about rust being faster than C
<mcrod>
and I don't believe that, at all
<netbsduser>
heat: which way is that?
<netbsduser>
there is something i think linux does which i am thinking of adopting
<netbsduser>
namely page tables being typesafe by RCU
<netbsduser>
the reason is i want to be able to access bit update without holding locks of any sort on arches with software accesed bits
CryptoDavid has quit [Quit: Connection closed for inactivity]
<heat>
>namely page tables being typesafe by RCU
<heat>
haha
<heat>
linux does NOT do that
<heat>
i mean
<heat>
it does, depending on the arch
<heat>
page tables are typesafe by-a-series-of-locks
<Ermine>
did I ignite rust discussion?
<mcrod>
no
<mcrod>
i went off on a tangent
<heat>
if you hold the mmap sem, page tables are typesafe. if you hold any of the rmap locks (anon OR file), page tables are typesafe
<heat>
if you hold the page table locks, they are also typesafe
<Ermine>
mcrod: phew
<netbsduser>
as far as i could see none of these held in the fast path for accessed bit updating on risc-v
<heat>
on x86, they don't do RCU page table walking, rather they use irq disabling
<heat>
because page tables are only recycled after IPIs, and as long as you have irqs off you can't get the IPI
<heat>
for riscv they *might* use rcu
hwpplayer1 has joined #osdev
<heat>
this is also broadly only useful for certain things like GUP or maybe A bit updating
<heat>
most page table traversals require you to hold *some* locks at least, to ensure page table and VMA stability
<heat>
i theorize you can get far with seqlocks but haven't given it a try
<netbsduser>
what, i have been fooled
<netbsduser>
the `pt_rcu_head` in struct ptdesc (page alias for pages that are page table pages) is used seemingly only on S390 and PowerPC
<heat>
yep
<heat>
i assume rv uses irq disabling + IPIs as the rcu mechanism there
<netbsduser>
it seems a fair bet
<netbsduser>
and it looks also like rather than requiring a kmem_cache, pt allocation can be directly from the page allocator (on arches or configurations of arches where that's possible)
<heat>
yep that's what i do too
<heat>
also
<heat>
fwiw kmalloc (and possibly kmem_cache_create'd caches??) shells out to the page allocator directly for big allocs
<heat>
on linux that is
<netbsduser>
i do it unconditionally at present (on m68k with its 256/512 byte tables, i always install 8/16 PTEs in the closer-to-root) however i felt that trick would get a bit sour if the page size is 64k
<heat>
well for all my archs i'm yet to deal with non-page-sized page tables
<netbsduser>
i might never either, but it menaces me, and it's costing quite a bit of effort to rethink the current dependency on stashing page table related stuff in the page struct - but i like messing around with vm stuff more than messing with anything else, so i am happy with that
xenos1984 has quit [Read error: Connection reset by peer]
<netbsduser>
it's also an opportunity to get away from the dependency of vm object page tracking on being based in page-sized tables
<netbsduser>
i am fairly sure at least the struct radix_node_struct in linux is always typesafe by RCU and that this facilitates lockless lookups
<heat>
yes
<heat>
actually i don't think it's typesafe by rcu
<heat>
just rcu freed
<netbsduser>
looks like that's the case, they reuse space used to point to a "private_list for tree user" for the rcu node
<Matt|home>
am i going to get yelled at if i paste some code i've been working on that isn't osdev related? i don't have any questions about it, just wanted to show it off -_-
<Matt|home>
yes yes i know what the shunting yard algorithm is. im currently doing a bit of a coding challenge with my family. we're writing different versions of a calculator
<Matt|home>
for me, i have 3 versions. 1) is my own algorithm (which i hoped was more elegant than this one). 2) is a regular tokenizer. 3) is some magical bs i haven't decided yet
<heat>
currently im facing a refactoring of my pid subsystem and, like, i need to decide on my locking scheme
<heat>
TRADITIONAL UNIX just slaps a big read-write spinlock on this (linux tasklist_lock, freebsd allproc_lock/proctree_lock or whatever they're called)
<heat>
but like, you can do a little better for sure
<heat>
currently i think my code is just slightly incorrect and prone to races
<nikolar>
Interesting
<nikolar>
What exactly do you mean by pid subsystem
<zid>
handing out unique pids?
<heat>
pid allocation, lookup, and managing process groups/sessions
<zid>
process bookkeeping then
<zid>
(rather than process management)
<nikolar>
Ye
<heat>
note that pid is not exactly a process id but more of an entity itself
<heat>
like, fork() guarantees that a pid with active pgrps/sessions cannot be handed out
<zid>
process_info_block[pid] = task_new();
<nikolar>
I imagine handing out unique pids can be as simple as atomically incrementing
<nikolar>
Everything else though is harder :P
<heat>
until you reach INT_MAX
<nikolar>
Yeah
<zid>
max processes: 32768
<nikolar>
Kek
<zid>
just keep looping
<heat>
or that yeah, max processes is usually way lower
<nikolar>
Is that realistic though heat
<nikolar>
I have no clue
<heat>
depends on the pid max
<nikolar>
I imagine 64 bits is plenty
<zid>
to be fair, it'll only be slow like, ONCE
<zid>
if you have 32000 processes loaded, and you run out and go back to 0 from 32767
<heat>
you can't have 64 bits at all
<zid>
then you'll just scan back to 30k
<zid>
once
<heat>
pid_t is defacto an int (dont tell sortie)
<zid>
pid_t should be an avx512 word
<zid>
and have status bits
<heat>
default pid max for linux is 32768 so once you create 32K procs you start allocating for real vs just bumping next_pid++
<sortie>
I'm with zid
<zid>
64 bit group, 64 bit pid-in-group, etc
<nikolar>
sortie, so a full cache line just for the pid :P
<sortie>
It's the only way to be sure
<heat>
hey sortie dont make me pull out the theo quote
<sortie>
I am joking here :)
<sortie>
Though not about my pid_t
<heat>
64-bit pid_t is blasphemous
<heat>
it does not embody the spirit of UNIX
<nikolar>
Lol how so
<heat>
idk it just doesn't
<the_oz_>
>don't look at it on the stack tho...
<heat>
for one pid_t is fairly new
<sortie>
I'm DEEP in POSIX right now trying to work out what POSIX even says about the crazy test I even wrote that produces different results on every OS
<nikolar>
heat that's fair enough
<heat>
its like, what if had fd_t open(const char *path, int flags, ...)
<sortie>
The Unix spirit is that pid_t is unique and that race conditions are rare enough to be basically 'doesn't happen'
<heat>
fd_t would *have* to be an int
<sortie>
Part of the typedef situation is that POSIX just invented a bunch of them
<heat>
no, the UNIX spirit is that pid_t allocates semi-cyclically
<sortie>
Before we went 64-bit
<sortie>
So it was easy for all the 32-bit systems to switch
<zid>
heat: I still think things should be 'fixed' to use pid_t though
<zid>
and changing the size is a good way to do it ;)
<nikolar>
The original unix (tm) spirit was to have a fixes array of struct proc and you just allocate from that :L
<the_oz_>
the unix spirit solves counting enumerations of things once and relies on it most of the time
<sortie>
heat: So fd_t could totally have happened
<nikolar>
s/fixes/fixed
<sortie>
HWND
<heat>
zid, probably but sortie has a pain in the ass just to fix printf sites
<zid>
yea printf is an issue with changing types eh
<heat>
it requires fucking <inttypes.h> and a new printpid macro
<the_oz_>
thus, get this, big int that scales from 8 bits to forever
<heat>
yeah, or a FUCKING INTTYPES.H MACRO
<heat>
i dont think i've ever used one successfully without googling
<zid>
the macros are gay
<zid>
PRIu64 can suck a cock
<sortie>
The usual sortie & heat debates, to be studied for many decades henchforth. I say heat is just reinventing Linux with a different skin and where's the fun in that let's explore the true Unix spirit, heat says that my inventions are crazy and blasphemous and violate the true spirit of Unix
<zid>
kek
<zid>
sortie: But if you change things, you can't copy paste linux source code, and where would he be then!?
<sortie>
PRIdPID ummm soo <sys/types.h> with the appropriate feature macros oh god heat is pulling up in a black van
<the_oz_>
remember being nonconventional is dangerous
<heat>
cue andrew tate saying the kings of old wanted UNIX
<heat>
(can't find the clip)
<zid>
the sex trafficer?
<the_oz_>
He's a dirty pimp
<heat>
yes
<zid>
good that you can't then
<heat>
but it was a dank unix meme :(
<heat>
sortie, i say POSIX is so underspecified it itself is a violation of the true spirit of UNIX
<heat>
despite being committee'd to death by shitty corporate UNIX and red hat
<zid>
bullshit
<zid>
the spirit of unix is that everybody does something very slightly different
<sortie>
heat, I'm reading line 18159 of POSIX which is not even 15%, and my reaction is, man, sure is a lot of POSIX
<the_oz_>
I'm starting to think to move to mostly a string based type
<the_oz_>
instead of numeric types
<the_oz_>
just general disgust at the calling convntion and overreliance on the stack paradigm
<the_oz_>
but now I have a new problem, general disgust at the string data type
<heat>
strings are definitely yucky
<heat>
fucking whitespace
<heat>
UNICOD
<heat>
E
<the_oz_>
even the best kind is disgusting, utf-8
<the_oz_>
\v
<sortie>
"An implementation shall document any condition not specified by this volume of POSIX.1-2024 under which the implementation generates signals." ← lol, seems like I have some documentation to write
<the_oz_>
SHALL is defined MAY. job done
<zid>
An implementor shall document their debit card number, name, year of expiry and CV2 number by emailing it to zid
<heat>
zid, that is *part* of the spirit of UNIX, but the spirit of UNIX IMO is also following the steps around mainline UNIX systems (early research unix, SYSTEM V, then later the BSDs/SunOS, now Linux)
<heat>
like pid allocation has always worked in a certain fashion, thus spirit of UNIX
<sortie>
“While a process is stopped, any additional signals that are sent to the process shall not be delivered until the process is continued, except SIGKILL which always terminates the receiving process.“ ← woot here's my smoking gun, my weird ass test involving SIGSTOP is well defined per POSIX
<zid>
nie
<sortie>
Since I can't atomically send a signal and write to a pipe at the exact same time, I can SIGSTOP a process to make both conditions true at the exact same time
<heat>
posix is garbage cmv
<sortie>
heat is just mad about xmas presents
<heat>
the POSIX spec should be a verbatim copy of UNIX SYSTEM V release 4
<heat>
sortie CAN YOU BELIEVE NO ONE GAVE ME A COPY OF THE ISO POSIX.1 2024 SPEC
<heat>
IM SO UPSET
PapaFrog has quit [Ping timeout: 260 seconds]
<the_oz_>
If you want to be a part of posix, just wait and it will grow to encompass you in trappings of specification
<the_oz_>
no effort needed
<heat>
that's _if_ you care
<heat>
afaik only macOS and other legacy unices boast UNIX certification/POSIX compliance
<heat>
linux is definitely not compliant out of the box, netbsd tries, freebsd ... dunno about freebsd
<sortie>
heat: I mean I can share the copy I got from a friend with you
<zid>
Mr. Goo Gulsurch
<heat>
that friend dropped it from a truck
<kof673>
> I'm starting to think to move to mostly a string based type well...once you have pid_t or any other _t....then is it an "opaque type" i.e. not guaranteed to be an integer type you can increment/dec/subtract from eachother/etc. it is too late for that perhaps, but opaque would allow whatever...user can then must e.g. functions if they need to manipulate
<kof673>
*can then e.g. call functions
<heat>
oh lord
<the_oz_>
it's just a thing
<kof673>
lol i'm just saying why would you hardcode a string when you can go full meta lol
<heat>
typedef struct { unsigned long long pid; } pid_t;
<heat>
@sortie time for a change?
<the_oz_>
because if you use text for everything then everything is just another thing
<the_oz_>
mostly because limitations make it easier to reason about and with
<sortie>
kof673: POSIX does have explicit language to say pid_t and some other types must be arithmetic integer types
<kof673>
yeah, makes sense
<heat>
sad.
<kof673>
which means....C compiler (ignoring posix for the moment) has the sizes/representation/etc. for available "primitive integer types" that the language itself supports doing arithmetic on
<kof673>
c23 or whatever has those arbitrary-sized "integers" though i suppose...
<kof673>
it is a matter of time until someone uses those for whichever _t integer type....
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
netbsduser has quit [Ping timeout: 260 seconds]
<the_oz_>
last I looked (c99) the only type veriant that I care about was the exact kind but wasn't guaranteed to be implemnented
<the_oz_>
will have to check again for c23
<the_oz_>
so like (u)int[8/16/32/64]_t
<kof673>
yeah, c23 or something lets you just specify arbitrary number of bits, < 4 even, and do arithmetic, is my understanding, declare a var, pass to functions...use in structs i assume...
<kof673>
*< 8 even, such as a 5-bit type
<heat>
bitints are still ABI-fucky atm
<heat>
for the system v abi at least
<the_oz_>
what is the barebones called of the headers that are guaranteed no matter what host youy run it on? os-less? hostless?
<zid>
honestly I think it should be more 'fashionable' to use one-off structs like that
<zid>
to add types
<heat>
the_oz_, freestanding
<the_oz_>
stdint.h and others I can't remember
<zid>
using enums would be one way but *they're not fucking type checked*
<the_oz_>
yes!
<the_oz_>
thank you
<zid>
heat: Can you explain to me why enum BOB { bob_a }; enum FRED { fred_a }; enum BOB b = fred_a; is legal, what the fuck is the point of the tag name?
<zid>
It's the only place you use it
<heat>
nope can't explain it
<nikolar>
Documentation lol
<zid>
I don't get what possible reason you could want to not make that a warning in the spec, or the compiler
<heat>
C++ added an enum class syntax to give you stronger type checking on it
<childlikempress>
used to be that not only were enum members not namespaced, neither were struct fields
<childlikempress>
so you could say struct foo { int x; }; struct bar { int y; }; struct foo f; f.y = 7
<zid>
and yet they added tag names to structs and uniqued them
<zid>
and then they added tag names to enums and
<zid>
forgot?
<childlikempress>
hence why you'll see struct fields prefixed, like the tv_ in tv_sec/nsec
<heat>
enum members still aren't namespaced
<nikolar>
zid nah who cares about that, what we really need is nullptr_t
<heat>
childlikempress, that's only partially true
<zid>
nikolar: oh right good point
<nikolar>
*needed
<heat>
prefixing stuff was required BACK IN THE REALLY OLD DAYS
<nikolar>
Also don't forget uwus and meows
<heat>
it just became good style
<heat>
for grepping and all
<zid>
uwuptr_t
<nikolar>
Kek
<heat>
nikolar, you do realize that if they added enum type checking they would be adding a C++ feature right?
<the_oz_>
ptr_t*
<the_oz_>
*squints*
<zid>
no they should have added it in 1989
<heat>
you'd cry regardless
<nikolar>
heat yeah so?
<zid>
C++ spec gets all the attention, we know that
<zid>
C gets handmedowns
<zid>
but usually useless ones
<zid>
useful ones would be an improvement
<nikolar>
What we get is shittier c++ instead of actual improvements
<heat>
the outcry is "hurr durr C is becoming C++"
<heat>
and will be regardless of things being useful
<zid>
They just can't be arsed to write spec documents just for C, unless they can get C as a bonus for writing one for C++ they don't bother
<heat>
just like nullptr is useful but hurr durr C is becoming C++
<zid>
nullptr is not useful
<zid>
The listed reason it exists is "C++ COMPATIBILITY"
<nikolar>
nullptr doesn't solve a single problem that NULL didn't solve
<the_oz_>
*squints*
<zid>
NULL has a bug, but they didn't fix that
<zid>
lol
<nikolar>
Lol
hwpplayer1 has quit [Quit: bye]
<sortie>
Hmm hey so all of my new os-test ppoll tests turned out to be well defined by POSIX after reading a bunch :) Tonight I found bugs in DragonflyBSD, Hurd, and Linux
<zid>
we've known about it for 30 years, so now it's "too late" apparently
<nikolar>
The actual solution would've been to define NULL as (void *)0
<nikolar>
Boom
<nikolar>
Done
<heat>
NULL has a bug and will have that bug forever
<heat>
that's not happening and you know it
<zid>
right, so we add a keyword that acts like null but without the bug.. which means you need a C23 compiler
<nikolar>
Well any implementation that does nullptr already defines NULL like that
<zid>
so just fucking
<zid>
make -std=c23, have a fixed NULL
<sortie>
zid: undefined?
<nikolar>
Yeah exactly zid
<heat>
implementation of what, C? can you even legally define NULL as nullptr?
<zid>
sortie: Pardon?
<the_oz_>
LEGALLY
<nikolar>
heat: eh?
<the_oz_>
you can do whatever the fuck you want
<sortie>
I may have implemented POSIX 2024 but I draw the line at C99 what is this C23 bullshit
<zid>
C99 is my normal limit
<zid>
C11 I use *very* occasionally for anonymous unions
<zid>
And I only use like, two things from C99 anyway
<nikolar>
Lol
<zid>
VLA syntax (but not vlas), and designated initializers
<heat>
i use GNU11
<zid>
gnu99
<zid>
is pretty gud
<nikolar>
it's pretty gnud
<heat>
gnu99 is pretty nice but gnu11 is pretty nicer
<the_oz_>
I just haven't looked at my c99 code in so long that I decided to take up the c23 that clang has implemented so far just because.
<heat>
prettier and nicer actually
<nikolar>
I like atomics honestly so I'm sticking to c11
<sortie>
A lot of my POSIX 24 missing stuff is actually that I never bothered to implement a lot of new C11 standard library stuff that nobody actually uses
<heat>
dont you dare having a MEMORY MODEL and THREADS and LOCKS
<zid>
heat is clang EVIL
<heat>
definitely
<heat>
UB? i'll delete your function instead
<zid>
oh that is clang, whoops
<zid>
kek
<zid>
gcc and clang are both non-evil
<zid>
would be annoying tbh, to disable bits of syntax just because I made VLAs an error
<nikolar>
Kek
<zid>
if()s in your parser
<heat>
cl.exe is the least evil compiler yet
<sortie>
clang-cl ftw
<zid>
cl-ang.exe is
<heat>
cl.exe does not engage in the satanic ritual of optimizing code
<zid>
good
<zid>
that means it won't do a clang and delete all your code
<nikolar>
cl.exe barely even compiles code
<the_oz_>
superoptimization
<the_oz_>
0 runtime
<the_oz_>
you get NOTHING! you LOSE good DA~Y sdir
PapaFrog has joined #osdev
* isabella
is trying to do the satanic ritual by hand in a weird environment but it's fkn hard ;-;