On Wed, May 21, 2025 at 10:23 AM Andriy Gapon <a...@freebsd.org> wrote: > > On 21/05/2025 10:28, Lexi Winter wrote: > > you are completely right. since we (for some reason, that i don't > > really understand) can't add new error codes to errno, we should stop > > using errno to indicate errors except where POSIX requires this.
One of the problems with new errno values is that they break our ABI. This is a paradoxical result on its surface, but the last time we added a new errno value this issue showed up. The big issue, IIRC, is for statically linked binaries could get errno values that would overflow the arrays of error messages. > I once had this idea, probably not original, that if we usually use 32-bit > variables to pass around error / status codes, then why not split up those > bits > for some special uses. > > E.g., lowest 10 or 12 bits could be actual error codes. > > But highest, say, 8 or 10 bits could encode a domain of interpretation (to > use a > term borrowed from IPsec). > Domain number zero would be a POSIX or legacy domain and error codes in it > would > be the standard errno codes. > Then we could have a different domain (or several) for FreeBSD-specific error > codes. > > Some middle bits could be used to further subdivide a domain into modules or > subsystems with their own error codes. > There could be some private (application specific) domains. > > But, of course, a larger repertoire of error codes is still not as flexible > and > powerful as an ability to pass a specific error string along with an error > code. VMS did variations of this... It was both good and bad. It was a sharp edge that you needed to understand when writing C code in early versions of VAX-C because sometimes it was hidden nicely behind the traditional Unix interfaces, and other times it wasn't. We could pass additional data back to userland. However, that too would be an ABI change. We could pass it in "R0" like we do errno, but then any assembler would need to mask it like the mask we'd add to libc. errno itself can't change: you can't require clients to mask the values and all accesses in the tree to errno are via the errno macro. However, go and rust do their own thing and would need to be modified if we tried to expand the reported value out. The other way to report this would be via something new. There's no new register we can report this on in most architectures: they all have proscribed roles that we can't change (or that would be unwise for use to change). There's some temp registers on some architectures we might get away with using since their values aren't preserved across system call boundaries. But if we can't use a register, then we'd have to make a note of it in the threads structure so we could add a. system call to return it, which does start to get messy since the thread structure is somewhat optimized for size and fitting in cache lines. And if we're going to grow the thread structure, we'd want to maybe just store the string (though memory management issues popup).... In short, I'd love to widen the interface, but there's a number of practical issues in the way. Warner
