ISO C Technical Corrigendum 2

ISO C Technical Corrigendum 2 (TC2) has been approved. Even leaner than its predecessor TC1, it consists only of small changes in response to Defect Reports, and will be of interest mostly to compiler and test suite vendors. In a few cases, it codifies behavior that everybody knew was correct but that was inadequately expressed in the Standard; in others, it changes the name for something (or introduces a new one), but does not affect behavior at all.

This text is based on Paul Eggert's summary of Douglas A. Gwyn, ``C Standards Update'', The Journal of C Language Translation 6, 3 (March 1995), 150-156, with additional material from Paul Eggert and Jutta Degener.

• There is a new kind of storage duration, allocated. The objects that malloc, realloc, and calloc return have allocated storage duration. Their lifetime ends with the end of the program or a call to free or realloc.

  This does not change the behavior of any program; it just expresses something every C programmer knew implicitly.

• The following are now locale-specific, not implementation-defined:
  • shift states used for the encoding of multibyte characters
  • character sets for isalnum, isalpha, iscntrl, islower, isprint, isupper
  • the interpretation of setlocale's second argument (if neither "C" nor "")
  • additional subject sequence forms for strtod, strtol, strtoul
  • strerror's returned string

  Strictly conforming programs - programs that rely on nothing but Standard C and behave the same on all its implementations - are allowed to exhibit locale-specific behavior, but not implementation-defined behavior. This change has made more programs strictly conforming.

• va_start and va_end must be invoked in corresponding pairs. The pairs cannot nest: for example, the behavior of `va_start(a, foo); va_start(a, foo); va_end(a); va_end(a);' is undefined.

• An incomplete structure or union type in one translation unit is compatible with a complete structure or union type in another unit.

  For many years, C programmers have simulated abstract data types with pointers to incomplete structures or unions. Outside the implementing module, the pointer is treated as an opaque pointer type; inside, an additional structure or union declaration completes the type and gives access to its members. This change allows that practice.

• Freestanding environments can have reserved external identifiers.

• The implementation-defined integer type compatible with an enumerated type must be capable of representing the enumeration members' values.

• An enumerated type is complete at the } ending the enumeration.

  Before TC2, the C standard did not specify when an enumerated type is completed.

• String literals need not be distinct even if not identical, so long as their elements have appropriate values. For example, ("a" == "ba"+1 && "a" == "a\0b") can yield 1. A similar rule applies to wide string literals. String and wide string literals can share space too; for example, ("a" == (void *) L"a") can yield 1.

• Passing a type (after promotion) not expected by a library function with variable number of arguments yields undefined behavior.

• `return X;' in main is not precisely equivalent to `exit(X);', since the dynamic storage of main vanishes as main returns.

  For example, the following program has undefined behavior:

  #include <stdio.h>
  #include <stdlib.h>
  
  void goodbye(void)
  {
      printf("Hello, World!\n");
  }
  
  int main(void)
  {
      char buf[20];
      setvbuf(stdout, buf, _IOFBF, sizeof(buf));
      atexit(goodbye);
      return 0;
  }
  

  The program becomes strictly conforming if one replaces main's return 0; with exit(0);.