4 ms·

Unless your OS is virtual machine that checks the structure of the user program, at some point, your typed data will have to be a set of numbers and/or a byte s

Unless your OS is virtual machine that checks the structure of the user program, at some point, your typed data will have to be a set of numbers and/or a byte stream. Granted, the set of numbers required for utf-8 `connect` is a little less efficient than your system call no. but that's hardly a highly typed API. Anything with less mechanical sympathy that's designed for _any_ user program to access it will have to pay similar costs.

IshKebab 4y ago
It's not highly typed no, but it does force the use of a highly typed API. How many languages provide a string-based interface to the connect() syscall?
- cropcirclbureau 4y ago
  Languages and kernels don't exactly have the same design considerations. Types and compilers are trying to help you write valid programs for your benefit. A kernel only has access to machine code representation of your possibly buggy or malicious program. Sure, your language or libc might provide a convenient and object based API to the kernel but these are just wrappers over the basic number and pointer to C struct soups based syscall APIs that machine code can interface with. I.e. there's nothing exactly preventing you from providing the wrong numbers and bad structs aside from the "higher layer in the stack". At least you're allowed to mispell `cnect` accessibly so from the shell. There are ways around this ofc like the Android Runtime that requires any code that interfaces with it to be written in Java adjacent bytecode that gets compiled to machine code (and cached) by the runtime (after being checked I imagine).
  - IshKebab 4y ago
    > there's nothing exactly preventing you from providing the wrong numbers and bad structs aside from the "higher layer in the stack" Right, mistakes are possible in both cases. But why pick the design that is more likely to lead to mistakes (on both sides of the interface) and is slower? There's just no good reason to do it like that.

IshKebab 4y ago

It's not highly typed no, but it does force the use of a highly typed API. How many languages provide a string-based interface to the connect() syscall?

cropcirclbureau 4y ago
Languages and kernels don't exactly have the same design considerations. Types and compilers are trying to help you write valid programs for your benefit. A kernel only has access to machine code representation of your possibly buggy or malicious program. Sure, your language or libc might provide a convenient and object based API to the kernel but these are just wrappers over the basic number and pointer to C struct soups based syscall APIs that machine code can interface with. I.e. there's nothing exactly preventing you from providing the wrong numbers and bad structs aside from the "higher layer in the stack". At least you're allowed to mispell `cnect` accessibly so from the shell. There are ways around this ofc like the Android Runtime that requires any code that interfaces with it to be written in Java adjacent bytecode that gets compiled to machine code (and cached) by the runtime (after being checked I imagine).
- IshKebab 4y ago
  > there's nothing exactly preventing you from providing the wrong numbers and bad structs aside from the "higher layer in the stack" Right, mistakes are possible in both cases. But why pick the design that is more likely to lead to mistakes (on both sides of the interface) and is slower? There's just no good reason to do it like that.