5 ms·
> no matter how many times they get clobbered in the face by the consequences of not learning it. While I do think that the boundary should be set at the libc
by AshamedCaptain 2y ago
> no matter how many times they get clobbered in the face by the consequences of not learning it.
While I do think that the boundary should be set at the libc level just out of design cleanliness, I fail to see what the "consequence" of not doing so is. You're just changing the instruction binaries use for syscalls from a relative jump to a trap (or whatever), but you still have all the problems with data type sizes, function "versions" and the like which are what this discussion is about.
- dmitrygr 2y ago> I fail to see what the "consequence" of not doing so is. TFA ?
- AshamedCaptain 2y agoNo. How would it benefit TFA _at all_? For all practical purposes Linux currently has _two_ stable boundaries, libc (glibc) and kernel. If you move it so that the stable boundary is only the kernel, you still have this problem. If you move it so that the stable boundary is only libc, you still have this problem. In fact, TFA's problem comes from applications passing time_ts around, which is strictly a userspace problem, and the syscall interface is almost entirely ortogonal. Heck, the 32-bit glibc time_t functions probably use the 64-bit time_t syscalls these days...