Technical questions emerge about syscall design and data freshness
3 Nov 2 11:33 AM · 9d ago · 1 comment · 1 source · development 3 of 3
Developers raise questions about why syscalls vary across architectures despite API standardization, discuss build process and staleness risk, and note that on x86_64/x32 the syscall number resides in eax not rax.
“I've long thought that the kernel should duplicate every existing syscall that takes a null–terminated string by pointer with an otherwise identical syscall that takes the string by pointer, capacity, and length instead.”
db48x, HN commenter · hn ↗guitmz Developer
The whole story articlespostscomments the bright band is this development · numbered dots are the others · click one to jump
What people said 3 voices · verbatim
-
It’s a side issue, but I’ve long thought that the kernel should duplicate every existing syscall that takes a null–terminated string by pointer with an otherwise identical syscall that takes the string by pointer, capacity, and length instead. It would be a huge boon to programs written in modern languages. I keep meaning to search the kernel…
-
Why also capacity?What I think would make sense is a change to the C API where the error code is an out parameter and not that ugly thread local errno. But I guess that's not big enough of an issue for people/languages that use libc as system call interface.
-
Modern languages .. or more specifically .. modern compilers for those languages .. can surely sustain a pointer, capacity and length wrap to pointer until null ..
All 3 developments of Developer releases updated Linux syscall reference with 27… →
Hacker NewsNewswiresMastodon