From: Ken Raeburn <raeburn@mit.edu>
Date: Thu, 12 Feb 2009 20:35:15 +0000 (+0000)
Subject: Don't pass negative numbers to strerror
X-Git-Tag: krb5-1.8-alpha1~634
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=b2c96206c3d6c8d253cc8ed2f4cc859e9c61c217;p=thirdparty%2Fkrb5.git

Don't pass negative numbers to strerror

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@21988 dc483132-0cff-0310-8789-dd5450dbe970
---

diff --git a/src/util/support/errors.c b/src/util/support/errors.c
index d85ba42443..4111ed478b 100644
--- a/src/util/support/errors.c
+++ b/src/util/support/errors.c
@@ -113,6 +113,20 @@ krb5int_get_error (struct errinfo *ep, long code)
     if (fptr == NULL) {
 	unlock();
     no_fptr:
+	/* Theoretically, according to ISO C, strerror should be able
+	   to give us a message back for any int value.  However, on
+	   UNIX at least, the errno codes strerror will actually be
+	   useful for are positive, so a negative value here would be
+	   kind of weird.
+
+	   Coverity Prevent thinks we shouldn't be passing negative
+	   values to strerror, and it's not likely to be useful, so
+	   let's not do it.
+
+	   Besides, normally we shouldn't get here; fptr should take
+	   us to a callback function in the com_err library.  */
+	if (code < 0)
+	    goto format_number;
 #ifdef HAVE_STRERROR_R
 	if (strerror_r (code, ep->scratch_buf, sizeof(ep->scratch_buf)) == 0) {
 	    char *p = strdup(ep->scratch_buf);