Tools

Sun Microsystems has provided a new version of the lint(1) program with the 5.0 version of the Sun WorkShop^TM Compilers C. It has been enhanced to detect potential 64-bit problems and is useful in making code 64-bit safe. In addition, the -v option to the C compiler can be very helpful. It helps the compiler perform additional and stricter semantic checks. It also enables certain lint-like checks on the named files.

When you clean up code to be 64-bit safe, use header files that have the correct definition of the derived types and data structures for the 64-bit world. In other words, use the header files present in the Solaris 7 operating environment.

For more information on the debugging capabilities of the Sun WorkShop Compilers C and lint(1), see the Sun WorkShop C User's Guide.

lint(1)

lint(1) can be used on both 32-bit and 64-bit code. Use the -errchk=longptr64 option for code that is intended to be run in both 32-bit and 64-bit environments. The -errchk=longptr64 flag checks portability to an environment in which the size of long integers and pointers is 64 bits and the size of plain integers is 32 bits.

The -Xarch=v9 option should be used to lint code intended to be run in the 64-bit SPARC environment. Use the -errchk=longptr64 option together with the -Xarch=v9 option to generate warnings about potential 64-bit problems for code to be run on 64-bit SPARC.

The -D__sparcv9 option to lint is no longer necessary and should not be used.

When warnings are generated, lint(1) prints the line number of the offending code, a warning message that describes the problem, and notes whether a pointer was involved. It can also indicate the sizes of types involved. The fact that a pointer is involved and the size of the types can be useful in finding specific 64-bit problems and avoiding the pre-existing problems between 32-bit and smaller types.

Though lint gives warnings about potential 64-bit problems, it cannot detect all problems. You must remember that not all warnings generated by lint are true 64-bit problems. In many cases, code that generates a warning can be intentional and correct for the application.

Some of the warnings to consider are shown in the following example.

warning: conversion of pointer loses bits 
warning: assignment causes implicit narrowing conversion 
warning: cast to pointer from different-bit integer  
warning: cast from bigger-bit integer to smaller-bit integer
warning: assignment of bigger-bit integer to smaller-bit integer
warning: bigger-bit constant truncated to smaller bits by assignment 
warning: passing bigger-bit integer arg, expecting smaller-bit integer:
  routine name(arg argument number)
warning: passing bigger-bit integer constant arg, expecting smaller-bit
  integer: routine name(arg argument number))
warning: function argument (number) type inconsistent with format
  printf (arg argument number) type used:  (format) type expected file (line)
warning: function argument (number) type inconsistent with format:
  scanf (arg  argument number)  type used: (format) type expected file (line)
warning: cast from bigger-bit constant expression to smaller-bit integer [lint warns about this only if the constant expression will not fit into the type into which it is being cast.] 
 

Warnings for a given source line can be suppressed by placing a /*LINTED*/ comment on the previous line. This is useful where you have really intended the code to be a specific way. An example might be in the case of casts and assignments. Exercise extreme care when using the /*LINTED*/ comment because it can mask real problems. Refer to the Sun WorkShop C User's Guide or the lint(1) man page for more information on the usage of the lint(1) command.