<bslsk05>
SlugOS/SlugOS - A minimal OS (0 forks/0 stargazers/CC0-1.0)
edr has quit [Quit: Leaving]
<zid>
ThatOSDeveloper: Sounds like you read the stack wrong then? did you push 1 / push 2 / push 3 etc at the start of an otherwise generic handler or osmething then try to pop it off?
<heat>
gotta pray and fast for intel
<ThatOSDeveloper>
oh crap I never pushed it LOL
<ThatOSDeveloper>
wait no I did
<zid>
where am I looking
<zid>
ah, init
MiningMarsh has quit [Ping timeout: 252 seconds]
<ThatOSDeveloper>
inside of src/init/interrupt and inside of isr.s and exception.c
<heat>
well for one there's a big problem
<ThatOSDeveloper>
what?
<heat>
in that you never pop the state back out
<ThatOSDeveloper>
oops
<zid>
biggest problem I noticed is that you have your * on the wrong side of this char
<ThatOSDeveloper>
kinda new to assembly lol
<zid>
disgraceful behaviour
<ThatOSDeveloper>
and eh with C, I mean I am mid with it, only known it for a few years
<heat>
isr_no_err_stub never pushes anything either
<heat>
childlikempress, BASED paulmck memory models i must add
<nikolar>
helpful as always zid :P
<ThatOSDeveloper>
oh yeah, I guess I am using cdecl?
<kof673>
* united states federal territory, they don't claim the land per se...federal territory is defined as outside any of the geographical states :D
<zid>
for example, the only one I ever remember off the top of my head, rdi = first parameter, rsi = second parameter, rdx = third parameter, ..., stack aligned to 16
<zid>
okay so cdecl says your args are on the stack
<ThatOSDeveloper>
oh, now I think I know what you mean
<zid>
you've pushed like 12 args, then retrieved 1 arg
<zid>
a pointer
<ThatOSDeveloper>
so do I just need to push like ebp (the stack frame)
<nikolar>
zid: pretty sure that's sysv
<nikolar>
rdi, rsi, rdx, rcx
<ThatOSDeveloper>
or is ebp the stack pointer?
<nikolar>
stack
<heat>
no, push esp
<ThatOSDeveloper>
oh esp okay
<heat>
also, your order is completely fucked
<nikolar>
esp - stack pointer
<nikolar>
ebp - base pointer
<zid>
you either want to do void exception(int arg1, int arg2, int arg3, int arg4, ...) or actually push esp first, so that your first thing on the stack is infact, a pointer to all that other crap :P
<zid>
I recommend the latter
<ThatOSDeveloper>
so I would need to do push %esp?
<zid>
s/first/last
<heat>
yes
<ThatOSDeveloper>
okay then I push all the other stuff?
<zid>
push esp just copies the current (which is the 'end') value of the stack pointer, to the stack, making it the first argument to your function call, and at the 'end' of the stack, is all the other crap you pushed to it
<heat>
no!
<zid>
push esp last, it needs to be the first argument to your function, and it needs to have the address of 'all the other crap'
<nikolar>
no! = NaN
<heat>
nikolar, js?
<ThatOSDeveloper>
right because assembly does it backwards compared to C right!
<heat>
ThatOSDeveloper, i think you dont understand the stack
<zid>
if you pushed it first, its value would be the saved eip of the assembly routine or whatever
<heat>
you really need to
<nikolar>
heat: just in general
<nikolar>
no is indeed not a number
<nikolar>
neither is no!
<ThatOSDeveloper>
listen man I barely understand C let alone assembly, I am impressed I even got this far on my own
<heat>
ok, then understand the stack
<zid>
You might wanna look at godbolt more, in future
<ThatOSDeveloper>
so if I push it last, it is the very top of the stack which then goes to the function right?
<ThatOSDeveloper>
well goes to the function first
<zid>
the last thing you pushed is the first thing to be popped, yes
<heat>
yes
<ThatOSDeveloper>
so do I need to pop it after exception handler?
<nikolar>
yes
<heat>
and the way you're pushing things will come up with a very broken stack frame
<zid>
cdecl says if you should or should not
<ThatOSDeveloper>
heat: sounds about right
<ThatOSDeveloper>
got to admit, I got pretty far on my own.
<heat>
you need to push in reverse wrt the struct
<heat>
like, the stack grows down right?
<zid>
stack cleanup column for cdecl in the wiki page: caller
<heat>
and C structs grow up
<heat>
so, looking at exception_frame_t, ds needs to be the last thing you push
<zid>
so the caller needs to remove the parameters, your pushed esp, but then you also need to remove that temporary local struct you made in the callee
<heat>
then eax, then ecx, then edx, yadda yadda
<ThatOSDeveloper>
so if I push all my stuff first (in the code) then at the end of my code (right before exception_handler is called)
<heat>
last thing you push *before the push %esp for the argument*
<ThatOSDeveloper>
so I want to push all of my crap, then esp, then call the function, then pop it all?
<zid>
yes
<heat>
nice dog btw
<zid>
normally you could use ebp to achieve that, but if you use ebp, you'll corrupt it
<ThatOSDeveloper>
so do not push ebp
<zid>
you can push it, that only changes what's on your stack
<ThatOSDeveloper>
so pushing it changes it?
<zid>
you can push it, that only changes what's on your stack
<ThatOSDeveloper>
oh lol
<zid>
You need to *not* corrupt ebp, inside an interrupt handler
<zid>
so you can't do the usual mov ebp, esp; push esp stuff
<ThatOSDeveloper>
wait did I do that?
<zid>
That's what almost all cdecl functions do
<heat>
no you did not
<zid>
Your problem appears to be reading comprehension
<zid>
[01:32] <zid> normally you could use ebp to achieve that, but if you use ebp, you'll corrupt it
<zid>
NORMALLY ONE COULD, PLEASE DO NOT
<ThatOSDeveloper>
I think I got it, I am going to try and make those mods now, so just in case, if a C stack grows upwards, if I do it in assembly, I would need to push it the exact opposite way?
<zid>
C doesn't have a stack
<heat>
yes
<ThatOSDeveloper>
okay thank you
<heat>
a C *struct* goes upwards
<heat>
an x86 stack grows downwards
<ThatOSDeveloper>
yes struct is what I meant
<zid>
ah yes, compounds/arrays, go forwards
<zid>
a[0] is before a[1]
<zid>
a.member0 is before a.member1
<heat>
note: you do not need to pop your arguments
<ThatOSDeveloper>
oops scrolled over it, (at 8.1 now LOL)
<zid>
also figure 6-4 has the same info
<zid>
and is technically the correct one for you, I think
<ThatOSDeveloper>
what version
<zid>
all of them
<heat>
gotta read man
<heat>
please pleas eplease just read man pelase read PLEASE i mean PLEASE JUST READ
<ThatOSDeveloper>
I mean like version 78 or like version 86 or which one of the manual ontent-details/671200/intel-64-and-ia-32-architectures-software-developer-s-manual-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4.html
<heat>
fuck do you mean which version
<zid>
it's a figure number, not a page number
<zid>
it's the order the pictures are in, in chapter 6, interrupt handling
<zid>
of volume 3
<ThatOSDeveloper>
okay
<ThatOSDeveloper>
looking thru it now
<ThatOSDeveloper>
6.14.5 Interrupt Stack Table got it
<zid>
no, that's 6.14.5
<zid>
you want FIGURE 6-4 or FIGURE 6-9
<ThatOSDeveloper>
yeah figure 6-9 IS 6.14.5
<nikolar>
kek
<zid>
no, it is not
<ThatOSDeveloper>
its just the image, but 6.14.5 explains it in words
<zid>
6.14.5 is a chapter, about the ia-32e stack table
<zid>
in its own words "an alternative to the modified legacy stack-switching mechanism described above"
<zid>
Above being the table I want you to look at, it's literally, 100%, NOT that
<zid>
A) It's an entirely different method to the normal one and B) You're not in ia-32e mode
<ThatOSDeveloper>
I thought ia-32e is just 32bit mode
<zid>
Did you read that, in the manual
<zid>
or did you just wildly guess, after assuming
<ThatOSDeveloper>
I see your point now
<ThatOSDeveloper>
but figure 6-9 covers the same thing and it says IA-32e and you told me to use it
<zid>
it's pretty easy to guess what ia-32e means even, if you look at say
<zid>
figure 6-9
<ThatOSDeveloper>
I am looking at that, it still makes no sense to me
<zid>
It describes two different stack layouts, one legacy, and one ia-32e, and the legacy one matches your registers
<zid>
and the ia-32e matches different, extended, registers
<zid>
that you don't have
<ThatOSDeveloper>
oh that makes more sense, I assume legacy is just normal 32bit mode and IA-32e is 64bit mode (guess on regist starting with R like RSP and RFLAGS and such)
<ThatOSDeveloper>
or 64bit registers
<zid>
Yes, that is a MUCH better assumption
<ThatOSDeveloper>
tysm for explaining that.
<zid>
I really hate that I had to
<zid>
you were trying to find if eflags was pushed or not, remember
<heat>
i mean, that is okay, x86 is complicated
<ThatOSDeveloper>
yeah it is, and well ARM is, ... far worse
<heat>
arm is actually not worse
<heat>
riscv is even simpler
<ThatOSDeveloper>
riscv is good, but not really used anyware AFAIK
<ThatOSDeveloper>
anywhere*
<heat>
sure
<nikolar>
riscv in, in fact, not good
<nikolar>
it's a sucky arch
<nikolar>
s/in/is
<ThatOSDeveloper>
so if I push a stack I just need to push what is in figure 6-9?
<ThatOSDeveloper>
(for a bare bones thing)
<heat>
it was already pushed for you
<heat>
you need to push the rest
<ThatOSDeveloper>
oh that makes more sense
<heat>
your exception frame struct is largely correct
<ThatOSDeveloper>
oh thank god!
<ThatOSDeveloper>
except for a bit of the order I assume
<heat>
the order in the asm is completely fucked wrt the C struct
<ThatOSDeveloper>
I am fixing that order now
<ThatOSDeveloper>
and what do I push at the end?
<ThatOSDeveloper>
it was ebp right?
<heat>
wdym
<heat>
esp
<ThatOSDeveloper>
esp okay
<ThatOSDeveloper>
so I tried to push in the right order but now I get 1166609477
<bslsk05>
wiki.osdev.org: User:A22347/Printfure - OSDev Wiki
<ThatOSDeveloper>
I mean I can run it thu a debugger
<ThatOSDeveloper>
trying to rn
<ThatOSDeveloper>
just got to my exception handler
<ThatOSDeveloper>
I should go back and stop it at my exception handler macro
<heat>
no, check the values there
<ThatOSDeveloper>
like the int_num?
<heat>
yes
<ThatOSDeveloper>
for some reason it will not let me stop there I dunno I guess GDB does not like stepping at push instructions
<heat>
there = C
<heat>
do it in C
<ThatOSDeveloper>
do it when I am in the C handler?
<ThatOSDeveloper>
I tried, it will not let me look at its value
<ThatOSDeveloper>
do I need to specify to look inside of the struct that is passed?
<heat>
what?
<ThatOSDeveloper>
like would I need to do print frame.int_num?
<ThatOSDeveloper>
or something like that
<heat>
frame->int_num
<ThatOSDeveloper>
oh thx
<ThatOSDeveloper>
so I do get (gdb) print frame->int_num
<ThatOSDeveloper>
$1 = 0 but whenever I pass it it seems to fail.
<heat>
ok, your printf is fucked
<heat>
you're welcome.
<ThatOSDeveloper>
perhaps, but then why does %d and such work everywhere else?
<ThatOSDeveloper>
it does not seem to be fucked anywhere else and reports everything right everywhere else
<heat>
i dont know
<ThatOSDeveloper>
imma try something weird that might work
<ThatOSDeveloper>
its not my printf
<ThatOSDeveloper>
I just tried something independent of it
<ThatOSDeveloper>
it seems to be my get_exception_message of all things
<ThatOSDeveloper>
at least I think
<ThatOSDeveloper>
no it cant be that
<heat>
what exception message are you getting?
<ThatOSDeveloper>
Unkown since get_exception_message does that when it gets a strange number
sbalmos has joined #osdev
<ThatOSDeveloper>
I will use the debugger again to see exactly when it gets fucked up
<ThatOSDeveloper>
strange right when I call get_exception_message it gets to 25 of all things instead of 0 which it is.
<ThatOSDeveloper>
then it becomes 0 again
<ThatOSDeveloper>
it stays 0 but for some reason fails as a Unknown exception
<ThatOSDeveloper>
then out of nowhere it becomes 1779231875
<ThatOSDeveloper>
I should try to back it up into another thing and try that instead
<geist>
sometims that sort of thing is because your stack isn't aligned properly
<geist>
i haven't read the entire backlog, but double check that
<ThatOSDeveloper>
maybe? I dunno how would I check that
<geist>
you should absolutely make sure it is to start, and then it'll probably not get out of aignment
<ThatOSDeveloper>
but that would make no sense of it changing over functions if my stack was misaligned
<ThatOSDeveloper>
and even if it was all my other functions should fail
<geist>
it changing over functions?
<ThatOSDeveloper>
more like lines, but yeah
<ThatOSDeveloper>
goes from every number under the sun man
<geist>
no it wouldn't. it tends to show up on printf because it's probably the only thing using varargs
<geist>
and misaligned stacks tend to not show up until then
<geist>
because the compiler will emit code based on that
<geist>
depends on the arch of course
<ThatOSDeveloper>
I did it in GDB, it changes, like from one function to the next, its 32bit
<geist>
i didn't read the whole backlog but what arch are you on?
<ThatOSDeveloper>
32bit
<ThatOSDeveloper>
i386
<ThatOSDeveloper>
(I think)
<geist>
mm, kk. you think?
solremn has joined #osdev
<ThatOSDeveloper>
yeah its i386 (checked with makefile)
<geist>
kk
remn has quit [Ping timeout: 260 seconds]
<ThatOSDeveloper>
I get the same number, so at least the printk is consistant
<ThatOSDeveloper>
its always 1166609477
<ThatOSDeveloper>
welp, no solution in sight for me tonight
<ThatOSDeveloper>
gn
ThatOSDeveloper has quit [Quit: WeeChat 4.5.1]
<heat>
committed a buncha shit tonight!!
<zid>
Both meanings?
<heat>
probably
<sbalmos>
did it clog your build pipelines?
<heat>
yep
<heat>
i have like 10 build jobs desperately building toolchains
troseman has joined #osdev
zhiayang has quit [Quit: oof.]
troseman has quit [Client Quit]
<geist>
heat: you go girl!
<heat>
yasss queeeen!!!
zhiayang has joined #osdev
<kof673>
"Who's house? Run's house. Who's house? Run's house. Martin..." a 90s joke for the young ones
<kof673>
*legacy joke
Halofreak1990 has joined #osdev
zhiayang has quit [Quit: oof.]
zhiayang has joined #osdev
<heat>
oh i finally got somewhat speedy tcp working
<heat>
the problem ended up being that i wasn't recognizing that the remote host supported SACKing, and these higher bandwidth transfers routinely drop packets it seems
<heat>
fixed that and went 500KB/s -> 5MB/s
dysthesis has quit [Remote host closed the connection]
guideX has quit [Remote host closed the connection]
cloudowind has quit [Ping timeout: 272 seconds]
guideX has joined #osdev
guideX has quit [Remote host closed the connection]
guideX has joined #osdev
heat has quit [Ping timeout: 264 seconds]
hwpplayer1 has joined #osdev
Halofreak1990 has quit [Ping timeout: 245 seconds]
netbsduser` has joined #osdev
McDonaldsWiFi has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
Arthuria has quit [Remote host closed the connection]
PublicWiFi has joined #osdev
netbsduser` has quit [Ping timeout: 246 seconds]
goliath has joined #osdev
cloudowind has joined #osdev
kof673 has quit [Ping timeout: 240 seconds]
kof673 has joined #osdev
Lucretia has joined #osdev
guideX_ has joined #osdev
guideX has quit [Ping timeout: 252 seconds]
Halofreak1990 has joined #osdev
cppLover0 has joined #osdev
<cppLover0>
hi
hwpplayer1 has quit [Read error: Connection reset by peer]
citrons has quit [Ping timeout: 252 seconds]
citrons has joined #osdev
GeDaMo has joined #osdev
Gordinator has joined #osdev
ryoskzypu has quit [Quit: ryoskzypu]
<geist>
hola
ryoskzypu has joined #osdev
<ring0_starr>
the hell was that guy about
<ring0_starr>
how do you start writing your own os but you barely understand C and you can't read documentation
<ring0_starr>
and more importantly, why are you helping him heat
<ring0_starr>
way to encourage stupidity
<geist>
because we're nice people
<geist>
everyone starts off stupid. sometimes helping people actually works
cppLover0 has quit [Ping timeout: 245 seconds]
cppLover0 has joined #osdev
<Mutabah>
For every 10 trolls, there's one misguided but enthusisastic person
<Mutabah>
I know because I was one
craigo has joined #osdev
Halofreak1990 has quit [Ping timeout: 246 seconds]
frytaped has quit [Quit: WeeChat 4.4.2]
Dead_Bush_Sanpa1 has joined #osdev
Dead_Bush_Sanpai has quit [Ping timeout: 248 seconds]
Dead_Bush_Sanpa1 is now known as Dead_Bush_Sanpai
solremn is now known as remn
<sortie>
Well said. Most osdev journeys are 'try until you fail' and then the act of failing teaches you something valuable. Many people come back later, try again, and fail on something new and exciting. Some people fail so much they succeed in the end
craigo has quit [Quit: Leaving]
<GeDaMo>
Success is just failing to fail :P
<nikolar>
since when is this a philosophy channel
<nikolar>
where are my language flame wars
<sortie>
zid: Do not recommend passing a structure by value to newbies when writing interrupt handlers. Most people will push all the registers, run the handler, and then pop all of them. But that will corrupt your registers. Because under the System V ABI, the values on the stack belong to the called function, which may clobber the stack. This does happen. Passing a struct registers by pointer is the easiest way. The new OS in question here did in fact correctly
<sortie>
pass it by pointer (see the push %esp int he code).
<bslsk05>
wiki.osdev.org: James Molloy's Tutorial Known Bugs - OSDev Wiki
<sortie>
(ok I see some of that code did change in the repo since then)
<sortie>
nikolar: osdev is just applied philosophy
guideX_ is now known as guideX
bauen1 has quit [Ping timeout: 252 seconds]
edr has joined #osdev
stolen has joined #osdev
frytaped has joined #osdev
frytaped has quit [Quit: WeeChat 4.4.2]
getz- has joined #osdev
getz has quit [Ping timeout: 244 seconds]
frytaped has joined #osdev
bauen1 has joined #osdev
<kof673>
philosophers were once considered dangerous, because they had the power to overthrow society -- messing with people's minds :D they were more dangerous than the flame wars, which was all talk :D
getz- is now known as getz
frytaped has quit [Ping timeout: 272 seconds]
Left_Turn has joined #osdev
frytaped has joined #osdev
hwpplayer1 has joined #osdev
q3lont has joined #osdev
sbalmos has quit [Quit: WeeChat 4.5.1]
goliath has quit [Quit: SIGSEGV]
Lucretia-backup has joined #osdev
Lucretia has quit [Ping timeout: 244 seconds]
Lucretia-backup is now known as Lucretia
bwani54 has joined #osdev
bwani54 has quit [Remote host closed the connection]
frytaped has quit [Quit: WeeChat 4.4.2]
sbalmos has joined #osdev
ebrasca has joined #osdev
Halofreak1990 has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 265 seconds]
frytaped has joined #osdev
cppLover0 has quit [Read error: Connection reset by peer]
Terlisimo has quit [Quit: Connection reset by beer]
Terlisimo has joined #osdev
<ring0_starr>
sortie: but running into this issue and debugging it on your own is part of the test.
<ring0_starr>
sure i get that it's not fair for a tutorial to contain the bug, but in order to "get so far" he's gotta have some kind of growing pain jeez
<ring0_starr>
"i can't believe i got so far and i barely understand C and asm" he says
<cloudowind>
kof673: its not the philosophers there its the questioning mind is found to be dangerous , what philosophers does is practicing this questioning , goodays people
<ring0_starr>
he's got gdb up and running at least so there's a start, with just a bit less help and a few more pushes into the right direction he might've been able to eventually figure it out
<ring0_starr>
in this tutorial on how to use a high level rust "crate", the language and lib itself changes so fast, the example code doesn't work at all, which as a rust beginner, makes me hate it as opposed to engaged
<ring0_starr>
i'm not going to see this self-inflicted difficulty as an interesting hook to get me to learn deeper concepts when i haven't become invested into it at all
<ring0_starr>
(self-inflicted as in, the thing i'm using created the difficulty, not me)
<\Test_User>
if just the tutorial's example code breaks like that I'd hate to have to rewrite a whole kernel on the same time schedule
<ring0_starr>
for an OS... i mean look, there are lots of OSes out there in the world today, some very successful and everywhere, but the thing is, these constructs he's playing with haven't changed in 40+ years
<ring0_starr>
so there's this inherently difficult thing that isn't a constantly moving target and there are many inspirational high quality examples of what you could have should you succeed
<ring0_starr>
that's far more motivational
<zid>
You know, I think nikolar might be my favourite serbian
goliath has joined #osdev
<nikolar>
am i the only serbian you know
<zid>
Yes.
<nikolar>
nice
<zid>
Heat is also my favourite portugal
<nikolar>
is he also the only portugal you know
<zid>
Yes.
<nikolar>
nice
<zid>
Imagine putting up with two :o
<nikolar>
oh no
<nikolar>
two heats
<zid>
nightmare
<nikolar>
i don't even want to imagine that
<zid>
At least it isn't two serbians, then we'd have three opinions about the balkans, 4 small wars, and 8 land border disputes.
<nikolar>
depends on if the other serbian is the kind that knows he's a serbian or is in denial :P
<zid>
"No, the house should be split down the middle." "No, we should split each room in half" "No, this is albania's fault, we shouldn't have to split anything"
<cloudowind>
kof673: i believe or should say only rational explanation would be the potential they do carry for a change , for the very same reason i believe revolutionists hasnt been very wellcomed though the history , same dont want change ,its not easy
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
<sortie>
ring0_starr: I mean yes definitely, debugging interrupt handlers is where the rubber hits the road, and you find out if you're ready for osdev. Many fail here, I suppose. My argument was that at least newbies shouldn't be given bad tutorials and bad advise that leads to footguns that make their life harder, and blow things up mysteriously down the road, and cause people to copy bad advise to others before the bug is found
<heat>
and paging too
<heat>
paging might be worse
<sortie>
Paging is way harder yeah
<sortie>
But people do interrupts first usually
<zid>
I did paging first lol
<zid>
the fuck do you need interrupts for
<sortie>
"i can't believe i got so far and i barely understand C and asm" is truly a learning experience. At that point, one has learned that those topics matter and for what purposes. That's a lot of value.
<sortie>
My argument here is to feel free to let newbies fail, because they learn from failure. But if you have mental time to help them, sure go ahead. Just, don't hate on them for trying to ask for help, you know?
bauen1 has joined #osdev
<sortie>
We're not here to explain all the basics, obviously, but we can provide pointers, and our patience runs out at one point. If the newbie doesn't take the help, well, the beginner will fail. But that's natural and a good time, and they'll come back stronger next time they try, with more experience :)
<sortie>
zid: lol that is a perfect quote
<zid>
I get more annoyed at people helping them, than them
<zid>
'helping'
<sortie>
Eh, you shouldn't. Just go about your day.
<zid>
I do
<sortie>
It's on people whether they want to provide some public service now and then
<zid>
and by helping, I mean, reinforcing that they don't need to learn anything, they can continue to paste tutorials and ask randos what to write at every step.
<zid>
sadge to see
<heat>
i mean yesterday you were pointing out how to read a manual soooooooo
<zid>
you should see fuz go at it heat
<zid>
he'll spend 3-4 hours teaching someone who can barely write a C program, some esoteric minutia that they will never use, and can't actually understand, until they start getting the repeated questions right, regardless of if they *actually* understand it
<zid>
I just kept shouting "read the manual" :P
<kof673>
$ echo -e 'f\n\n\n' # works ok, outputs f and 4 newlines $ echo `echo -e 'f\n\n\n'` # something is eating my precious newlines
<sortie>
kof673: Use printf. echo -e is all evil
<sortie>
kof673: You gotta quote your `` btw. It's just inlined and then the shell does the usual tokenization of whitespace
<sortie>
So "`foo`" or "$(foo)" if you prefer
<kof673>
no luck with printf "$(printf 'f\n\n\n')" narrator: <jeopardy music>
Turn_Left has quit [Ping timeout: 272 seconds]
<ring0_starr>
i think i'm done with teaching newbies
<ring0_starr>
there used to be this guy who i was teaching C/asm/shellcode/etc. and i spent a lot of time when i should've been doing WFH teaching him instead
<sortie>
kof673: printf doesn't have an implicit ending newline btw
<ring0_starr>
got in trouble with my bosses
<sortie>
kof673: And note how the shell removes one trailing newline whenever it expands a subshell like that
<ring0_starr>
he went MIA for like a year, came back and finished up all the assignments i gave him and was helping him work out
<ring0_starr>
meanwhile i'm in the doghouse
<ring0_starr>
they end up not appreciating it
<ring0_starr>
besides, chatgpt could give them more attention and energy than i ever could
<ring0_starr>
give them that
<ring0_starr>
ChatGPT OS
<sortie>
kof673: Huh. Looks like the shell actually removes all trailing newlines when expanding a $() or ``
<ring0_starr>
not an OS that integrates chatgpt, slight variations on the same basic OS that one gets when they ask chatgpt for help the whole way through
<sortie>
I would have expected it to only remove one trailing one
<ring0_starr>
the industrial-cut cookie they deserve with that lvl of effort
<sortie>
kof673: printf "$(printf 'f\n\n\n\nb\n \n\n')" is an interesting example
Arthuria has joined #osdev
netbsduser` has quit [Ping timeout: 272 seconds]
<heat>
i dont get this
<heat>
i've been looking at how linux enforces SO_SNDBUF limits on tcp sockets today
<heat>
in theory, you know, you set SO_SNDBUF and it limits the amount of crap you can send before blocking. okay.
<heat>
however, it seems that sometimes it decides to enforce the limit (in a not-so-precise way, it seems), other times it decides to stick as many bytes as it wants in the send queue
<zid>
kek
<heat>
there are like 500 fucking tunables and i dont know which ones influence this
<ring0_starr>
keep telling me about how determinism isn't important
karenw has joined #osdev
<heat>
yes you should be deterministically shitty and deterministically slow
<ring0_starr>
by the way isn't the way the kernel exposes tunables fun
<ring0_starr>
make sure there's no central data structure you can check, don't want people to be cognisant of the complexity they add when they decided to make that thing an option
<heat>
yes its fun, yes there is
<heat>
yes im tired about discussing this
<ring0_starr>
(i'm not happy about freebsd's sysinit list concept either)
<kof673>
sortie, it is just for a parser test, so i will just rewrite it to use a FILE * stream (or stdin) instead of command-line argument. just annoying :D
<ring0_starr>
yeah i don't need to discuss it. i just felt like venting. the issues that they create ought to be self-evident, but knowing people, they're gonna find something else to blame and solve a derivative problem
<ring0_starr>
i give up tbqh
<kof673>
re: newlines, i wonder if rc or es or other shells maybe have a "raw" way to do that though
karenw has quit [Ping timeout: 265 seconds]
Turn_Left has joined #osdev
<kof673>
"`printf 'a;\nb;\n '`" if i put a space, or "anything else" after it does not vanish so that works :/