Portability checks

Some nonportable code is flagged by lint in its default behavior, and a few more cases are diagnosed when lint is invoked with -p and/or -Xc. The latter tells lint to check for constructs that do not conform to the ANSI C standard. For the messages issued under -p and -Xc, check ``Using lint''.
Examples:

• In some C language implementations, character variables that are not explicitly declared signed or unsigned are treated as signed quantities with a range typically from -128 to 127. In other implementations, they are treated as nonnegative quantities with a range typically from 0 to 255. So the test

  char c;
  
  c = getchar();
  if (c == EOF) . . .
  

  where EOF has the value -1, will always fail on machines where character variables take on nonnegative values. One of lint's -p checks will flag any comparison that implies a ``plain'' char may have a negative value. Note, however, that declaring c a signed char in the above example eliminates the diagnostic, not the problem. That's because getchar() must return all possible characters and a distinct EOF value, so a char cannot store its value. This example, which is perhaps the most common one arising from implementation-defined sign-extension, shows how a thoughtful application of lint's portability option can help you discover bugs not related to portability. In any case, declare c as an int.

• A similar issue arises with bit-fields.
  When constant values are assigned to bit-fields, the field may be too small to hold the value. On a machine that treats bit-fields of type int as unsigned quantities, the values allowed for int x:3 range from 0 to 7, whereas on machines that treat them as signed quantities they range from -4 to 3. However unintuitive it may seem, a three-bit field declared type int cannot hold the value 4 on the latter machines. lint invoked with -p flags all bit-field types other than unsigned int or signed int. Note that these are the only portable bit-field types. The compilation system supports int, char, short, and long bit-field types that may be unsigned, signed, or ``plain.'' It also supports the enum bit-field type.
  

• Bugs can arise when a larger-sized type is assigned to a smaller-sized type. If significant bits are truncated, accuracy is lost:

  short s;
  long l;
  s = l;
  

  lint flags all such assignments by default; the diagnostic can be suppressed by invoking the -a option. Bear in mind that you may be suppressing other diagnostics when you invoke lint with this or any other option. Check the list in ``Using lint'' for the options that suppress more than one diagnostic.
  

• A cast of a pointer to one object type to a pointer to an object type with stricter alignment requirements may not be portable. lint flags

  int *fun(y)
  	 char *y;
  {
  	 return(int *)y;
  }
  

  because, on most machines, an int cannot start on an arbitrary byte boundary, whereas a char can. If you suppress the diagnostic by invoking lint with -h, you may be disabling other messages. You can eliminate the problem by using the generic pointer void *.

• ANSI C leaves the order of evaluation of complicated expressions undefined. What this means is that when function calls, nested assignment statements, or the increment and decrement operators cause side effects -- when a variable is changed as a byproduct of the evaluation of an expression -- the order in which the side effects take place is highly machine dependent. By default, lint flags any variable changed by a side effect and used elsewhere in the same expression:

  int a[10];
  main()
  {
      int i = 1;
      a[i++] = i;
  }
  

  Note that in this example the value of a[1] may be 1 if one compiler is used, 2 if another. The bitwise logical operator & can also give rise to this diagnostic when it is mistakenly used in place of the logical operator &&:

  if ((c = getchar()) != EOF & c != '0')