This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Friendlier EPERM.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]