lint for 32–bit and 64–bit
Environments

lint 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 option 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.

Starting with the Solaris 10 release, the -Xarch=amd64 option
should be used to lint code intended to be run in the 64–bit
AMD environment.

Note –

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

For a description of lint options, see the Sun
Studio 10: C User's Guide.

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.

Note –

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.

The sample program and lint(1) output below illustrate most
of the lint warnings that can arise in code that is not 64–bit
clean.

(The lint warning that arises from line 27 of this code sample
is issued 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 Studio 10: C User's Guide or
the lint(1) man page for more information.