This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Friendlier EPERM.
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Daniel J Walsh <dwalsh at redhat dot com>
- Cc: libc-alpha at sourceware dot org, Eric Paris <eparis at redhat dot com>, David Malcolm <dmalcolm at redhat dot com>
- Date: Tue, 8 Jan 2013 10:36:25 -0800 (PST)
- Subject: Re: Friendlier EPERM.
- References: <50EC5E21.4040002@redhat.com>
As described, that's a non-starter. strerror is a stateless function
that takes an errno value as argument. It's entirely normal for
programs to store errno values from failing calls, pass them around,
eventually call strerror with an errno value that came from an
operation on a different thread and/or from before many more
operations that have since set errno for unrelated reasons, etc. It's
even well-specified today that you can communicate an errno code to a
different process and evaluate it there.
It is indeed an unfortunate limitation of POSIX-like interfaces that
error reporting is limited to a single integer. But it's very deeply
ingrained in the fundamental structure of all Unix-like interfaces.
Frankly, I don't see any practical way to achieve what you're after.
In most cases, you can't even add new different errno codes for
different kinds of permission errors, because POSIX specifies the
standard code for certain errors and you'd break both standards
compliance and all applications that test for standard errno codes to
treat known classes of errors in particular ways.
You can certainly add some additional side channel of some kind with
more information about failures. But you really cannot shoehorn this
sort of thing into standard interfaces. It's just not that easy, sorry.
Thanks,
Roland