undefined | Better HN

0 pointslmm3d ago0 comments

> Which is a C ABI. Borland's Turbo C and C++Builder used different ABI than Microsoft C compiler did. GCC for Windows used to use a third, entirely different ABI as well.

Sure, you can do that. Userspace code can use any ABI it wants, or none. But again, why, what do you gain?

And regardless of whether it's "the" ABI or merely "a" ABI, that ABI presumably has a representation for strings and allows passing them around - and while you certainly could use a different representation in your program (or in the OS internals) and transform strings back and forth when calling the OS (or when receiving calls from userspace), you probably don't want to. At which point we're back at needing a way to write strings in an in-memory format to OS-standard files in the filesystem.

0 comments

Joker_vD3d ago

> But again, why, what do you gain?

Performance? Codegen simplicity? Why, again, must one use the syscall ABI for anything that is not a syscall?

> that ABI presumably has a representation for strings and allows passing them around

In this particular case, the API operates with binary buffers, not text strings. Sure, you can go the VMS way, or even IBM way, and turn files from binary blobs into arrays of fixed-length records (that's why C's fwrite/fread have both num and sz arguments: some OSes literally can't write data any other way).

> At which point we're back at needing a way to write strings in an in-memory format to OS-standard files in the filesystem.

Yes? Some text editors converted LFs to NULs to work on the text in memory, and then they'd convert NULs back into LFs on writing to the disk (IIRC). Both emacs and vi don't store text in memory the way it's layed out in the file; they translate it when writing to the disk.

Again, why do you want the OS to get involved into any of this? It's not the OS's job, period, stop trying to make the world an even worse place.

lmmOP2d ago

> Performance? Codegen simplicity? Why, again, must one use the syscall ABI for anything that is not a syscall?

If you can figure out an ABI that gives you significant advantages, sure, knock yourself out. But given that you're going to have to implement the syscall one anyway, if there's no compelling reason to use a different one then why make things more complicated?

> Again, why do you want the OS to get involved into any of this? It's not the OS's job, period

Again, why have a filesystem if you're not going to have any standardised structure for how to use it? Why have an OS at all if you're not going to give programs ways to interact with each other? The OS owns the filesystem, it should also define how it's used.

> stop trying to make the world an even worse place

Right back at you.

j / k navigate · click thread line to collapse