From b2c96206c3d6c8d253cc8ed2f4cc859e9c61c217 Mon Sep 17 00:00:00 2001 From: Ken Raeburn Date: Thu, 12 Feb 2009 20:35:15 +0000 Subject: [PATCH] Don't pass negative numbers to strerror git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@21988 dc483132-0cff-0310-8789-dd5450dbe970 --- src/util/support/errors.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/util/support/errors.c b/src/util/support/errors.c index d85ba4244..4111ed478 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); -- 2.26.2