classification
Title: os.strerror does not check for out of range argument
Type: behavior Stage:
Components: Extension Modules Versions: Python 3.0, Python 2.6, Python 2.5
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: belopolsky, georg.brandl, schmir
Priority: normal Keywords: patch

Created on 2008-03-19 01:24 by belopolsky, last changed 2008-05-11 21:15 by georg.brandl. This issue is now closed.

Files
File name Uploaded Description Edit
posix-strerror.diff belopolsky, 2008-03-19 01:28 Patch against revision 61579
Messages (7)
msg64023 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-03-19 01:24
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.
msg64024 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-03-19 01:30
Please ignore the first patch.  I don't have enough permissions to remove 
it.
msg64039 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2008-03-19 05:02
Removed earlier version
msg64105 - (view) Author: Ralf Schmitt (schmir) Date: 2008-03-19 21:28
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.
msg64113 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-03-19 22:02
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.
msg64446 - (view) Author: Ralf Schmitt (schmir) Date: 2008-03-24 22:41
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.
msg66670 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-05-11 21:15
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.
History
Date User Action Args
2008-05-11 21:15:27georg.brandlsetstatus: open -> closed
resolution: rejected
messages: + msg66670
nosy: + georg.brandl
2008-03-24 22:41:59schmirsetmessages: + msg64446
2008-03-19 23:38:00terry.reedysetnosy: - terry.reedy
2008-03-19 22:02:57belopolskysetmessages: + msg64113
2008-03-19 21:28:36schmirsetnosy: + schmir
messages: + msg64105
2008-03-19 05:02:25terry.reedysetnosy: + terry.reedy
messages: + msg64039
2008-03-19 05:01:30terry.reedysetfiles: - posix-strerror.diff
2008-03-19 01:30:17belopolskysetmessages: + msg64024
2008-03-19 01:28:56belopolskysetfiles: + posix-strerror.diff
2008-03-19 01:25:22belopolskysetcomponents: + Extension Modules
2008-03-19 01:24:52belopolskycreate