The behavior of these functions is affected by the current locale. Those functions that have implementation-defined aspects only when not in the "C" locale are noted below.

The term printing character refers to a member of an implementation-defined set of characters, each of which occupies one printing position on a display device; the term control character refers to a member of an implementation-defined set of characters that are not printing characters. [Footnote: In an implementation that uses the seven-bit ASCII character set, the printing characters are those whose values lie from 0x20 (space) through 0x7E (tilde); the control characters are those whose values lie from 0 (NUL) through 0x1F (US), and the character 0x7F (DEL).]

#include <ctype.h>
int isalnum(int c);

#include <ctype.h>
int isalpha(int c);

#include <ctype.h>
int iscntrl(int c);

#include <ctype.h>
int isdigit(int c);

#include <ctype.h>
int isgraph(int c);

#include <ctype.h>
int islower(int c);

#include <ctype.h>
int isprint(int c);

#include <ctype.h>
int ispunct(int c);

#include <ctype.h>
int isspace(int c);

#include <ctype.h>
int isupper(int c);

#include <ctype.h>
int isxdigit(int c);

#include <ctype.h>
int tolower(int c);

#include <ctype.h>
int toupper(int c);

This was truly a new style of programming. C programs tended to be small and devoted to a single function. The tradition until then was to write huge monoliths that offered a spectrum of services. C programs read and wrote streams of human-readable characters. The tradition until then was to have programs communicate with each other via highly structured binary files. They spoke to people by producing paginated reports with embedded carriage controls.

Those of us who wrote character manipulation programs before C wrote mostly in assembly language. A few of us more daring souls used FORTRAN as well. That took dedication, however. FORTRAN had few facilities, and fewer standards, for trafficking in characters.

So the early toolsmiths writing in C under UNIX began developing idioms at a rapid rate. We often found ourselves sorting characters into different classes. To identify a letter, we wrote

if ('A' <= c && c <= 'Z'
    || 'a' <= c && c <= 'z')
   .....

if ('0' <= c && c <= '9')
   ..... 

if (c == ' ' || c == '\t' || c
== '\n')
   .....

Opinions also differed on the makeup of certain character classes. White space has always suffered notorious variability. Should you lump vertical tabs in with horizontal tabs and spaces? If you include new lines (which are actually ASCII line feeds), should you also include carriage returns (which UNIX reserves for writing overstruck lines)? The easier it is to get tools to work together, the more you want them to agree on conventions.

The natural response was to introduce functions in place of these tests. That made them at once more readable and more uniform. The idioms for letter, digit and white space became

if (isalpha(c))
   .....

if (isdigit(c))
   .....

if (isspace(c))
   .....

They were. A typical text processing program might average three calls on these functions for every character from the input stream. The overhead of calling so many functions often dominated the execution time of the programs. That led some programmers to back off from using the standard functions that had evolved. It led others to develop a set of macros to take their place.

C programmers tend to like macros. They let you write code that is as readable as calling functions but is much more efficient. You just have to be ready for a few surprises:

• The macro may expand into much more code than a function call, even if it executes faster than the function call. If your program expands the macro in many places, it can grow surprisingly larger.
• The macro may expand to a subexpression that doesn't bind as tight as a function call. This is an unacceptable surprise and always has been. A liberal use of parentheses in the macro definition can eliminate such nonsense.
• The macro may expand one of its arguments to code that is executed more than once or not at all. A macro argument with side effects will cause surprises. While some C programmers consider such surprises acceptable, modern practice avoids them. Only two Standard C library functions, getc and putc, permit such unsafe behavior.

#define isxxx(c) (ctyptab[c] & XXXMASK)

One drawback to this approach is that the macro generates bad code for all the wrong arguments. Expand it with an argument not in the expected range and it accesses storage outside the translation table. Depending on the implementation, the error can go undetected or it can terminate execution with a cryptic message.

On a machine that represents type char the same as signed char, this is a common error. The function call isprint(c) looks safe enough. But say c has type char and holds a value with the sign bit set. The argument will be a negative value almost cetainly out of range for the function. Few programmers know to write the safer from isspace((unsigned char)c).

Nevertheless, translation tables remain the basis for many modern implementations of the character classification functions. They help the implementor provide efficient macros, even in the presence of multiple locales. And these functions remain important to the modern C programmer. You should use them wherever possible to sort characters into classes. They greatly increase your chances of having code that is both efficient and correct across varied character sets.

Let's start at the beginning. The classes defined by the character classification functions are:

digit — one of the ten decimal digits '0' through '9'

hexadecimal digit — a digit or one of the first six letters of the alphabet in either case, 'a' through 'f' and 'A' through 'F'

lower case letter — one of the letters 'a' through 'z', plus possibly others outside the "C" locale

upper case letter — one of the letters 'A' through 'Z', plus possibly others outside the "C" locale

letter — one of the lower case or upper case letters, plus possibly others outside the "C" locale

alphanumeric — one of the letters or digits

graphic — a character that occupies one print position and is visible when written to a display device

punctuation — a graphic character that is not an alphanumeric, including at least the 29 such characters used to represent C source text

printable — a graphic character or the space character ' '

space — the space character ' ', one of the five standard motion control characters (form feed, newline, carriage return, horizontal tab, or vertical tab), plus possibly others outside the "C" locale

control — one of the five standard motion control characters, backspace, alert (or bell), plus possibly others.

Note that two of these classes are open-ended even in the "C" locale. An implementation can define any number of additional punctuation or control characters. In ASCII, for example, punctuation also includes characters such as @ and $. Control characters include all the codes between decimal 1 and 31, plus the delete character, whose code is 127.

If you find all these classes confusing, take heart. So do I. I need a diagram to sort them all out. Figure 1 (taken from P.J. Plauger and Jim Brodie, Standard C, Microsoft Press, 1989) shows how the character classification functions relate to each other.

The characters in the rounded rectangles are all the members of the basic C character set. These are the characters you use to represent an arbitrary C source file. The C standard requires that every target character set contain all of these characters. Every target character set must also contain the null character, whose code is zero.

I have added single and double plus signs under some of the function names. A single plus sign indicates that the function can represent additional characters outside the "C" locale. A double plus sign indicates that the function can represent additional characters even in the "C" locale.

A target character set can contain members that fall in none of these classes. The null character is best left out of all classes, for example. The same character must not, however, be added at more than one place in the diagram. If it is a lower case letter, it is of course also in several other classes by inheritance. But a character must not be considered both punctuation and control, for example.

As you can see from the diagram, nearly all the functions can change behavior in a program that alters its locale. Only isdigit and isxdigit remain unchanged. If your code intends to process the local language, this is good news. The locale will alter islower, for example, to detect any additional lower case letter.

If your code endeavors to be locale independent, however, you must program more carefully. Supplement any tests you make with the character classification functions to weed out any extra characters that sneak in. Or get all your locale independent testing out of the way before your program changes out of the "C" locale.

If neither of these options is viable, you may have to revert part or all of the locale for a region of code. Begin the region with

#include <locale.h>
#include <stdlib.h>
#include <string.h>
   .....
   char *ls = setlocale(LC_TYPE, "C");
   if (ls)
      {
      char *ss = malloc(strlen(ls) + 1);
      ls = strcpy(ss, ls);
      }

   if (ls)
      {
      setlocale(LC_CTYPE, ls);
      free(ls);
      }

The important message is that Standard C introduces a new era. You can now write code more easily for cultures around the world, which is good. But you must now write code with more forethought. If it can end up in an international application, it may someday process characters undreamed of by early C programmers. Trust the character classification functions to contain the problem, to help you with it, and to delineate what can change.

Next month, I will discuss implementation issues for the functions and macros defined in <ctype.h>. I will also present code for the header and the functions. None of it is complex, but keeping it portable and adaptable to changing locales is a delicate matter. Stay tuned.