|
|
Subscribe / Log in / New account

Re: Friendlier EPERM.

From:  Roland McGrath <roland-AT-hack.frob.com>
To:  Daniel J Walsh <dwalsh-AT-redhat.com>
Subject:  Re: Friendlier EPERM.
Date:  Tue, 8 Jan 2013 10:36:25 -0800 (PST)
Message-ID:  <20130108183625.DF03D2C08D@topped-with-meat.com>
Cc:  libc-alpha-AT-sourceware.org, Eric Paris <eparis-AT-redhat.com>, David Malcolm <dmalcolm-AT-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




to post comments


Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds