kilic has quit [Remote host closed the connection]
kilic has joined #osdev
raykv423 has joined #osdev
Lucretia has quit [Remote host closed the connection]
<szatku>
It looks that somehow, the instruction is wrongly intepreted, and merged two instructions jmp, and first instruction from subroutine below entering to unreal mode
<heat>
what processor mode are you on?
<heat>
is the jmp 32 bits code or 16 bits?
<kof673>
> C's non-fixed size types seems to be the thing which is consensually a mistake so everyone has those sizes fixed now it is not a problem if you stick to c89. posix and beyond c89 decided to change it,
<kof673>
just draw a line between c89 and the modern world, and pick a side :D
<kof673>
c89 is already 128 and 256-bit ready
<heat>
everyone? who's everyone?
<kof673>
just quoting. ">"
<heat>
it's still super linux (not UNIX this time around) tradition to have long = native word
<heat>
int, short, char, long, long long (to a less deg) are still super widespread in most code
craigo has joined #osdev
<kof673>
yes, and while one can disagree with "the c indecision" people writing out of spec code, fixed-size types just let you easily fail via defines, alone they do not magically write code if a size and representation is not available
<karenw>
int/unsigned as a "I don't care, just give me a fast integer type" is common. char is common. The other types I only really see if calling apis that use those in their signature.
<karenw>
And char is guarenteed to be 1 byte. Okay, there's the slight issue on systems with CHAR_BIT != 8, but most people don't actively think about those
<kof673>
or, they are all "fixed size" just it varies what the particular fixed size is on a particular system :D
<kof673>
c just punted and said the hardware is separate. it is really a split between should cpu manufactureres be making languages or not, or indirectly influencing them
chiselfu1e is now known as chiselfuse
<kof673>
*urers
<kof673>
with the new bit thing you can simulate now and let the compiler provide unavailable types (sizes, anyhow) seemingly
<kof673>
so, the modern/future c went back to "flexibility" in a way, in that sense
szatku has quit [Quit: Client closed]
<kof673>
so now, there is or will be a way to get the compiler to "magically write code" for an arbitrary size
<clever>
i was recently looking into some data-formats, and found a wonky palettized format
<clever>
first, it has an array of N items in the pallette, then it has a semi packed array of n-bit ints
<clever>
if the palette has 8-15 items, then you can represent an index with 4 bits, so the main data is a packed array of 4bit ints, nice and evenly divisible
<clever>
but if the palette has 16-31 elements, you need a 5bit int, 12 x 5bit get packed into a 64bit int, and then an array of 64bit ints go into the main data structure!
<clever>
if only i could tell the compiler, i want a semi-packed array of N bit ints, (N selectable at runtime), where it doesnt cross a 64bit boundary
frytaped has quit [Ping timeout: 244 seconds]
<karenw>
There's probably some sepples template voodoo for that.
<heat>
people that use unsigned (as in unsigned a = 0; without the int) are lame and poopy faces
<heat>
same for people that use short int
<kof673>
and i am not against having a language that *only* provides 8/16/32/64 or whatever, just C predates that. i just say draw a line and pick either side is fine :D
<pog>
let x: i32;
<heat>
/votekick pog
* pog
zigs
<heat>
that's zig?
<pog>
maybe zig does var instead
<heat>
you'll be surprised to know that's also rust
<pog>
but that is zig's type notation
<pog>
zig shares a lot of syntactic similarity with rust afaik
<heat>
zig is what if rust but argh memory safety sux
<pog>
memory safety does suck
<pog>
does rust have arbitrary width integars tho
<heat>
tired memory safety stans vs wired cve fans
<pog>
zig can do let x: i10; and will enforce that width limit and throw overflow errors if you exceed it
<heat>
that sounds uhhhhhhhhhhhhhhhh weird
<pog>
it's not weird heat it's not weird
<heat>
typed bitfields
<heat>
what happens if you have an i10 *
<pog>
i don't remember what its pointer semantics are
<pog>
i haven't playd with it in awhile
heat_ has joined #osdev
hbag has quit [Quit: Ping timeout (120 seconds)]
heat has quit [Read error: Connection reset by peer]
<heat_>
never play, always horse around
<pog>
three little orphans one two three
frytaped has joined #osdev
vdamewood has joined #osdev
<sbalmos>
zig gets weird in explicitly passing around memory allocators
heat_ has quit [Ping timeout: 264 seconds]
Burgundy has quit [Ping timeout: 252 seconds]
<the_oz_>
I wonder if C's implementation will be the same as llvm's implementation
dysthesis has joined #osdev
PapaFrog has quit [Ping timeout: 264 seconds]
edr has quit [Quit: Leaving]
ajr has joined #osdev
<cloudowind>
sortie: when i think about absolute security or the lim for max security would where no securiy needed , where no individual needs to modify steal or hack anything , there is the absolute security until other species reaches to a level of intelligence and starts disrupting network syetsms of humans hehe
<cloudowind>
otherwise it will just go forever , with one securing other trying to break in
PapaFrog has joined #osdev
eluks has quit [Remote host closed the connection]
eluks has joined #osdev
dysthesis has quit [Remote host closed the connection]
raykv423 has quit [Quit: Connection closed for inactivity]
janemba has quit [Read error: Connection reset by peer]
janemba has joined #osdev
raykv423 has joined #osdev
emilrwx has quit [Quit: WeeChat 4.4.2]
cloudowind has quit [Ping timeout: 265 seconds]
emntn has joined #osdev
pross has joined #osdev
netbsduser has joined #osdev
goliath has joined #osdev
hwpplayer1 has joined #osdev
netbsduser has quit [Ping timeout: 248 seconds]
hwpplayer1 has quit [Remote host closed the connection]
Fingel has quit [Ping timeout: 272 seconds]
cloudowind has joined #osdev
karenw has quit [Ping timeout: 265 seconds]
hwpplayer1 has joined #osdev
hwpplayer1 has quit [Remote host closed the connection]
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]