Wrong use of ctype functions

[SDLBugzilla]

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Adds "unsigned char" casts in macro definitions. (SDL_stdinc.h.udif, text/plain, 2006-10-06 20:40:22 +0000, 726 bytes)

Reported in version: 1.2.11
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-10-06 20:35:17 +0000, Christian Biere wrote:

SDL_string.c uses a couple of ctype routines but always passes a value of type "char" as argument. This is wrong on platforms with char being signed because the value might be negative. These functions accept only values representable by an unsigned char or EOF. Other values cause undefined behaviour which includes bogus return values and even crashes. Some platforms like Linux/glibc sweep such bugs under the carpet on many others out-of-range values cause indeed crashes.
Therefore, char should always be casted to unsigned char for ctype functions like toupper, tolower, isidigit, isspace etc.

On 2006-10-06 20:40:22 +0000, Christian Biere wrote:

Created attachment 166
Adds "unsigned char" casts in macro definitions.

The attached patch adds unsigned char casts for the macros SDL_isspace(), SDL_isdigit(), SDL_toupper(), SDL_tolower() when they are mapped to the ctype functions. This makes them slightly different from the ctype functions because EOF (usually -1) is not handled. However, SDL only uses them for strings not FILE I/O e.g. fgetc(), so this modification should be sufficient. The advantage is that it fixes all 3rd party code which might have been using these incorrectly as well (modulo the mentioned caveat).

On 2007-02-12 06:15:03 +0000, Ryan C. Gordon wrote:

I would rather fix these at the individual calls in SDL_string.c ... changing the macro would be bad practice, since it adds an unexpected behaviour to it, even if it mostly works.

--ryan.

On 2007-02-15 06:13:52 +0000, Ryan C. Gordon wrote:

I corrected SDL_string.c directly.

Fixed in svn revision # 2980 for the 1.2 branch and # 2981 for the 1.3 branch.

--ryan.