os.strerror does not check for out of range argument

[abalkin]

BPO	2413
Nosy	@birkenfeld, @abalkin
Files	posix-strerror.diff: Patch against revision 61579

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2008-05-11.21:15:27.489>
created_at = <Date 2008-03-19.01:24:51.968>
labels = ['extension-modules', 'type-bug']
title = 'os.strerror does not check for out of range argument'
updated_at = <Date 2008-05-11.21:15:27.281>
user = 'https://github.com/abalkin'

bugs.python.org fields:

activity = <Date 2008-05-11.21:15:27.281>
actor = 'georg.brandl'
assignee = 'none'
closed = True
closed_date = <Date 2008-05-11.21:15:27.489>
closer = 'georg.brandl'
components = ['Extension Modules']
creation = <Date 2008-03-19.01:24:51.968>
creator = 'belopolsky'
dependencies = []
files = ['9755']
hgrepos = []
issue_num = 2413
keywords = ['patch']
message_count = 7.0
messages = ['64023', '64024', '64039', '64105', '64113', '64446', '66670']
nosy_count = 3.0
nosy_names = ['georg.brandl', 'belopolsky', 'schmir']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue2413'
versions = ['Python 2.6', 'Python 2.5', 'Python 3.0']

[abalkin]

ISO/ANSI C strerror indicates out of range error by setting errno, but
existing code incorrectly checks for NULL return value. Attached patch
(tested n Mac OS X) makes os.strerror raise ValueError for out of range
argument.

[abalkin]

Please ignore the first patch. I don't have enough permissions to remove
it.

[terryjreedy]

Removed earlier version

[schmir]

my manpage (debian testing) states:

POSIX.1-2001 permits strerror() to set errno if the call encounters an
error, but does not specify what value should be returned as the func‐
tion result in the event of an error. On some systems, strerror()
returns NULL if the error number is unknown. On other systems, str‐
error() returns a string something like "Error nnn occurred" and sets
errno to EINVAL if the error number is unknown.

So, I think this patch should be rejected.

[abalkin]

And on some system "Unknown error: nnn" is returned with no error indication.

Your concern that the patch is invalid on some unidentified system.
This concern
can easily be addressed by checking for NULL return *in addition* to
the errno check.

The real question is whether it is desirable to raise ValueError from
strerror() when
error code is out of bound. I would say the existing code intends to
do exactly that,
but th error check is incorrect on at least one popular platform. I
believe it is better
to raise an error because as a user, seeing "unknown error has
occurred" message,
is one of the worst experiences.

On the other hand, if the consensus is that strerror() should always
(short of out of
memory condition) return a string, then (assuming null return is a
possibility) the code
needs to be changed to return "Unknown error: nnn" instead of raising an error.

[schmir]

The current behaviour (without your patch) seems ok to me. I just wanted
to point out that the patch in its current form could break on some
platforms.

[birkenfeld]

IMO, the current behavior is the least problematic. It also mirrors the
rest of Python's posix-wrapping calls: if something usable is returned,
use it; if NULL is returned, raise an error.

For most people, "Unknown error XXX" or "Value error: strerror()
argument out of range" won't be much different in terms of user experience.

Rejecting this patch.