编辑器/阅读器

开发平台：

C/C++

msg.txt：源码内容

627 (arg. no. Integer) indirect object inconsistent with
format -- The type of an argument to scanf (or fscanf or
sscanf) was inappropriate to the format. However, the
argument was a pointer and it pointed to a quantity of the
expected size.
628 no argument information provided for function 'Symbol'
(Location) -- The named function was called but there was
no argument information supplied. Argument information
can come from a prototype or from a function definition.
This usually happens when an old-style function decla
ration indicates that the function is in a library but no
prototype is given for the function nor is any argument
information provided in a standard library file. This
message is suppressed if you are producing a lint object
module because presumably the object module will be
compared with a library file at some later time.
629 static class for function 'Symbol' is non standard -- A
static class was found for a function declaration within a
function. The static class is only permitted for
functions in declarations that have file scope (i.e.,
outside any function). Either move the declaration
outside the function or change static to extern; if the
second choice is made, make sure that a static declaration
at file scope also exists before the extern declaration.
Though technically the construct is not portable, many
compilers do tolerate it. If you suppress the message,
PC-lint/FlexeLint will treat it as a proper function
declaration.
630 ambiguous reference to symbol 'Name' -- If the +fab flag
is set, then if two structures containing the same member
name (not necessarily different kinds of structures) are
embedded in the same structure and a reference to this
member name omits one of the intervening (disambiguating)
names, this warning is emitted.
631 tag 'Symbol' defined differently at Location -- The
struct, union or enum tag Symbol was defined differently
in different scopes. This is not necessarily an error
since C permits the redefinition, but it can be a source
of subtle error. It is not generally a programming
practice to be recommended.
632 Assignment to strong type 'Name' in context: Context --
An assignment (or implied assignment, Context indicates
which) violates a Strong type check as requested by a
-strong(A... option. See Chapter 8.
633 Assignment from a strong type 'Name' in context: Context
-- An assignment (or implied assignment, Context indicates
which) violates a Strong type check as requested by a
-strong(X... option. See Chapter 8.
634 Strong type mismatch (type 'Symbol') in equality or
conditional -- An equality operation (== or !=) or a
conditional operation (? :) violates a Strong type check
as requested by a -strong(J... option. This message would
have been suppressed using flags "Je". See Chapter 8.
635 resetting strong parent of type 'Symbol', old parent ==
type 'Symbol' -- The strong parent of the given Symbol is
being reset. This is being done with a -parent option or
by a typedef. Note that this may not necessarily be an
error; you are being alerted to the fact that the old link
is being erased. See Chapter 8.
636 ptr to strong type 'Name' versus another type -- Pointers
are being compared and there is a strong type clash below
the first level. For example,
/*lint -strong(J,INT) */
typedef int INT;
INT *p; int *q;
if( p == q ) /* Warning 636 */
will elicit this warning. This message would have been
suppressed using flags "Je" or "Jr" or both.
637 Expected index type 'Symbol' for strong type 'Symbol' --
This is the message you receive when an inconsistency with
the -index option is recognized. A subscript is not the
stipulated type (the first type mentioned in the message)
nor equivalent to it within the hierarchy of types. See
Chapter 8. STRONG TYPES and also +fhx.
638 Strong type mismatch for type 'Name' in relational -- A
relational operation ( >= <= > < ) violates a Strong
type check as requested by a -strong(J... option. This
message would have been suppressed using flags "Jr". See
Chapter 8.
639 Strong type mismatch for type 'Name' in binary operation
-- A binary operation other than an equality or a
relational operation violates a Strong type check as
requested by a -strong(J... option. This message would
have been suppressed using flags "Jo". See Chapter 8.
640 Expected strong type 'Name' in Boolean context -- A
Boolean context expected a type specified by a
-strong(B... option. See Chapter 8.
641 Converting enum to int -- An enumeration type was used in
a context that required a computation such as an argument
to an arithmetic operator or was compared with an integral
argument. This warning will be suppressed if you use the
integer model of enumeration (+fie) but you will lose some
valuable type-checking in doing so. An intermediate
policy is to simply turn off this warning. Assignment of
int to enum will still be caught.
This warning is not issued for a tagless enum without
variables. For example
enum {false,true};
This cannot be used as a separate type. PC-lint/FlexeLint
recognizes this and treats false and true as arithmetic
constants.
642 Format char 'Char' not supported by wsprintf -- This
means that you are using an option of the form:
-printf(w... and you are using a format character not
supported by the Microsoft Windows function wsprintf. If
you are not really using wsprintf but are using the w flag
to get far pointers you should turn this message off.
643 Loss of precision in pointer cast -- A far pointer was
cast to a near pointer. Such casts have had disastrous
consequences for Windows programmers. If you really need
to make such a cast, you can do it in stages. If you cast
to a long first (i.e., some integral type that can hold
the pointer) and then into a shorter value, we don't
complain.
644 Variable 'Symbol' (Location) may not have been initialized
-- An auto variable was not necessarily assigned a value
before use. See Section 9.
645 Symbol 'Symbol' (Location) may not have been initialized
-- An auto variable was conditionally assigned a value
before being passed to a function expecting a pointer to a
const object. See Warning 603 for an explanation of the
dangers of such a construct. See Section 9.
646 case/default within Kind loop; may have been misplaced --
A case or default statement was found within a for, do, or
while loop. Was this intentional? At the very least,
this reflects poor programming style.
647 Suspicious truncation -- This message is issued when it
appears that there may have been an unintended loss of
information during an operation involving int or unsigned
int the result of which is later converted to long. It is
issued only for systems in which int is smaller than long.
For example:
(long) (n << 8)
might elicit this message if n is unsigned int, whereas
(long) n << 8
would not. In the first case, the shift is done at int
precision and the high order 8 bits are lost even though
there is a subsequent conversion to a type that might hold
all the bits. In the second case, the shifted bits are
retained.
The operations that are scrutinized and reported upon by
this message are: shift left, multiplication, and
bit-wise complementation. Addition and subtraction are
covered by Informational message 776.
The conversion to long may be done explicitly with a cast
as shown or implicitly via assignment, return, argument
passing or initialization.
The message can be suppressed by casting. You may cast
one of the operands so that the operation is done in full
precision as is given by the second example above.
Alternatively, if you decide there is really no problem
here (for now or in the future), you may cast the result
of the operation to some form of int. For example, you
might write:
(long) (unsigned) (n << 8)
In this way PC-lint/FlexeLint will know you are aware of
and approve of the truncation.
648 Overflow in computing constant for operation: String --
Arithmetic overflow was detected while computing a
constant expression. For example, if int is 16 bits then
200 * 200 will result in an overflow. String gives the
operation that caused the overflow and may be one of:
addition, unsigned addition, multiplication, unsigned
multiplication, negation, shift left, unsigned shift left,
subtraction, or unsigned sub.
To suppress this message for particular constant
operations you may have to supply explicit truncation.
For example, if you want to obtain the low order 8 bits of
the integer 20000 into the high byte of a 16-bit int,
shifting left would cause this warning. However,
truncating first and then shifting would be OK. The
following code illustrates this where int is 16 bits.
20000u << 8; /* 648 */
(0xFF & 20000u) << 8; /* OK */
If you truncate with a cast you may make a signed
expression out of an unsigned. For example, the following
receives a warning (for 16 bit int).
(unsigned char) OxFFFu << 8 /* 648 */
because the unsigned char is promoted to int before
shifting. The resulting quantity is actually negative.
You would need to revive the unsigned nature of the
expression with
(unsigned) (unsigned char) OxFFF << 8 /* OK */
649 Sign fill during constant shift -- During the evaluation
of a constant expression a negative integer was shifted
right causing sign fill of vacated positions. If this is
what is intended, suppress this error, but be aware that
sign fill is implementation-dependent.
650 Constant out of range for operator String -- In a
comparison operator or equality test (or implied equality
test as for a case statement), a constant operand is not in
the range specified by the other operand. For example,
if 300 is compared against a char variable, this warning
will be issued. Moreover, if char is signed (and 8 bits)
you will get this message if you compare against an inte
ger greater than 127. The problem can be fixed with a
cast. For example:
if( ch == 0xFF ) ...
if( (unsigned char) ch == 0xFF ) ...
If char is signed (+fcu has not been set) the first receives
a warning and can never succeed. The second suppresses the
warning and corrects the bug.
PC-lint/FlexeLint will take into account the limited
precision of some operands such as bit-fields and
enumerated types. Also, PC-lint/FlexeLint will take
advantage of some computations that limit the precision of
an operand. For example,
if( (n & 0xFF) >> 4 == 16 ) ...
will receive this warning because the left-hand side is
limited to 4 bits of precision.
651 Potentially confusing initializer -- An initializer for a
complex aggregate is being processed that contains some
subaggregates that are bracketed and some that are not.
ANSI recommends either "minimally bracketed" initializers
in which there are no interior braces or "fully bracketed"
initializers in which all interior aggregates are
bracketed.
652 #define of symbol 'Symbol' declared previously at Location
-- A macro is being defined for a symbol that had
previously been declared. For example:
int n;
#define n N
will draw this complaint. Prior symbols checked are local
and global variables, functions and typedef symbols, and
struct, union and enum tags. Not checked are struct and
union member.
653 Possible loss of fraction -- When two integers are
divided and assigned to a floating point variable the
fraction portion is lost. For example, although
double x = 5 / 2;
appears to assign 2.5 to x it actually assigns 2.0. To
make sure you don't lose the fraction, cast at least one
of the operands to a floating point type. If you really
wish to do the truncation, cast the resulting divide to an
integral (int or long) before assigning to the floating
point variable.
654 Option String obsolete; use -width(W,I) -- The option -w
is now used to set the warning level and should no longer
be used to specify the width of error messages. Instead
use -width with the same arguments as before to set the
width. To set the warning level to 3, for example, use
the option -w3, not -w(3).
655 bit-wise operation uses (compatible) enum's -- A bit-wise
operator (one of '|', '&' or '^') is used to combine two
compatible enumerations. The type of the result is
considered to be the enumeration. This is considered a
very minor deviation from the strict model and you may
elect to suppress this warning.
656 Arithmetic operation uses (compatible) enum's -- An
arithmetic operator (one of '+', or '-') is used to
combine two compatible enumerations. The type of the
result is considered to be the enumeration. This is
considered a very minor deviation from the strict model
and you may elect to suppress this warning.
657 Unusual (nonportable) anonymous struct or union -- A
struct or union declaration without a declarator was taken
to be anonymous. However, the anonymous union supported
by C++ and other dialects of C require untagged union's.
Tagged unions and tagged or untagged structs are rarely
supported, as anonymous.
658 Anonymous union assumed (use flag +fan) -- A union
without a declarator was found. Was this an attempt to
define an anonymous union? If so, anonymous unions should
be activated with the +fan flag. This flag is activated
automatically for C++.
659 Nothing follows '}' on line within struct/union/enum
declaration -- A struct/union/class/enum definition
occurred and the closing '}' was not followed on the same
line by another token. It looks suspicious. Missing
semi-colons after such definitions can be a source of
strange and mysterious messages. If you intentionally
omitted the semi-colon then simply place the token, which
follows, on the same line as the '}'. At the very least
follow the '}' with a comment.
660 Option String has no effect -- The indicated option had
no effect. Was this a mistake? Not all options are
tested for effectiveness. For example, in the sequence
-w2 -e720 the 2nd option has no effect but no report is
given since the nuisance value would be too high. The
message is reserved for cases when the non-effectiveness
would produce truly mysterious results.
661 possible access of out-of-bounds pointer ('Integer' beyond
end of data) by operator 'String' -- An out-of-bounds
pointer may have been accessed. See message 415 for a
description of the parameters Integer and String. For
example:
int a[10];
if( n <= 10 ) a[n] = 0;
Here the programmer presumably should have written n<10.
This message is similar to messages 415 and 796 but
differs from them by the degree of probability. See
Section 9.
662 possible creation of out-of-bounds pointer ('Integer'
beyond end of data) by operator 'String' -- An
out-of-bounds pointer may have been created. See message
415 for a description of the parameters Integer and
String. For example:
int a[10];
if( n <= 20 ) f( a + n );
Here, it appears as though an illicit pointer is being
created, but PC-lint/FlexeLint cannot be certain. See
also messages 416 and 797. See Section 9.
663 Suspicious array to pointer conversion -- This warning occurs
in the following kind of situation:
struct x { int a; } y[2];
... y->a ...
Here, the programmer forgot to index the array but the
error normally goes undetected because the array reference
is automatically and implicitly converted to a pointer to
the first element of the array. If you really mean to
access the first element use y[0].a
664 Left side of logical OR (||) or logical AND (&&) does not
return -- An exiting function was found on the left hand
side of an operator implying that the right hand side
would never be executed. For example:
if( (exit(0),n == 0) || n > 2 ) ...
Since the exit function does not return, control can never
flow to the right hand operator.
665 Unparenthesized parameter Integer in macro 'Symbol' is
passed an expression -- An expression was passed to a
macro parameter that was not parenthesized. For example:
#define mult(a,b) (a*b)
... mult( 100, 4 + 10 )
Here the programmer is beguiled into thinking that the
4+10 is taken as a quantity to be multiplied by 100 but
instead results in: 100*4+10, which is quite different.
The recommended remedy ( [22 section 20.4]) is to
parenthesize such parameters as in:
#define mult(a,b) ((a)*(b))
The message is not arbitrarily given for any
unparenthesized parameter but only when the actual macro
argument sufficiently resembles an expression and the
expression involves binary operators. The priority of the
operator is not considered except that it must have lower
priority than the unary operators. The message is not
issued at the point of macro definition because it may not
be appropriate to parenthesize the parameter. For
example, the following macro expects that an operator will
be passed as argument. It would be an error to enclose op
in parentheses.
#define check(x,op,y) if( ((x) op (y)) == 0 ) print( ... )
666 Expression with side effects passed to repeated parameter
Integer of macro 'Symbol' -- A repeated parameter within
a macro was passed an argument with side-effects. For
example:
#define ABS(x) ((x) < 0 ? -(x) : (x))
...
ABS( n++ )
Although the ABS macro is correctly defined to specify the
absolute value of its argument, the repeated use of the
parameter x implies a repeated evaluation of the actual
argument n++. This results in two increments to the
variable n. [22 section 20.6] Any expression containing
a function call is also considered to have side-effects.
667 Inconsistent use of qualifiers for symbol 'Symbol' (type
'Type' vs. 'Type') conflicts with Location -- A
declaration for the identified Symbol is inconsistent with
a prior declaration for the same symbol. There was a
nominal difference in the declaration but owing to the
memory model chosen there was no real difference. For
example, in large model, one declaration declares external
symbol alpha to be a far pointer and another declaration
omits the memory model specification.
668 Possibly passing a null pointer to function 'Symbol',
Context Reference -- A NULL pointer is possibly being
passed to a function identified by Symbol. The argument
in question is given by Context. The function is either a
library function designed not to receive a NULL pointer or
a user function dubbed so via the option -function. See
Section 10.1 Function Mimicry (function) and Section 9.2
Value Tracking.
669 Possible data overrun for function 'Symbol', argument
Integer exceeds argument Integer Reference -- This
message is for data transfer functions such as memcpy,
strcpy, fgets, etc. when the size indicated by the first
cited argument (or arguments) can possibly exceed the size
of the buffer area cited by the second. The message may
also be issued for user functions via the -function
option. See Section 10.1 Function Mimicry (function) and
Section 9.2 Value Tracking.
670 Possible access beyond array for function 'Symbol',
argument Integer exceeds Integer Reference -- This
message is issued for several library functions (such as
fwrite, memcmp, etc) wherein there is a possible attempt
to access more data than exist. For example, if the
length of data specified in the fwrite call exceeds the
size of the data specified. The function is specified by
Symbol and the arguments are identified by argument
number. See also Section 10.1 Function Mimicry (function)
and Section 9.2 Value Tracking.
671 Possibly passing to function 'Symbol' a negative value
(Integer), Context Reference -- An integral value that
may possibly be negative is being passed to a function
that is expecting only positive values for a particular
argument. The message contains the name of the function
(Symbol), the questionable value (Integer) and the
argument number (Context). The function may be a standard
library function designed to accept only positive values
such as malloc or memcpy (third argument), or may have
been identified by the user as such through the -function
or -sem options. See message 422 for an example and
further explanation.
672 Possible memory leak in assignment to pointer 'Symbol' --
An assignment was made to a pointer variable (designated
by Symbol), which may already be holding the address of an
allocated object, which had not been freed. The
allocation of memory, which is not freed, is considered a
'memory leak'. The memory leak is considered 'possible'
because only some lines of flow will result in a leak.
673 Possibly inappropriate deallocation (Name1) for 'Name2'
data -- This message indicates that a deallocation
(free(), delete, or delete[]) as specified by Name1 may be
inappropriate for the data being freed. The kind of data
is one or more of: malloc, new, new[], static, auto,
member, modified or constant. The word 'Possibly' is used
in the message to indicate that only some of the lines of
flow to the deallocation show data inconsistent with the
allocation.
674 Returning address of auto through variable 'Symbol' --
The value held by a pointer variable contains the address
of an auto variable. It is normally incorrect to return
the address of an item on the stack because the portion of
the stack allocated to the returning function is subject
to being obliterated after return.
675 No prior semantics associated with 'Name' in option
'String' -- The -function option is used to transfer
semantics from its first argument to subsequent arguments.
However it was found that the first argument Name did not
have semantics.
676 Possibly negative subscript (Integer) in operator 'String'
-- An integer whose value was possibly negative was added
to an array or to a pointer to an allocated area
(allocated by malloc, operator new, etc.) This message is
not given for pointers whose origin is unknown since a
negative subscript is in general legal.
677 sizeof used within preprocessor statement -- Whereas the
use of sizeof during preprocessing is supported by a
number of compilers it is not a part of the ANSI C or C++
standard.
678 Member 'Symbol' field length (Integer) too small for enum
precision (Integer) -- A bit field was found to be too
small to support all the values of an enumeration (that
was used as the base of the bit field). For example:
enum color { red, green, yellow, blue };
struct abc { enum color c:2; };
Here, the message is not given because the four
enumeration values of color will just fit within 2 bits.
However, if one additional color is inserted, Warning 678
will be issued informing the programmer of the undesirable
and dangerous condition.
679 Suspicious Truncation in arithmetic expression combining
with pointer -- This message is issued when it appears
that there may have been an unintended loss of information
during an operation involving integrals before combining
with a pointer whose precision is greater than the
integral expression. For example:
//lint -sp8 pointers are 8 bytes
//lint -si4 integers are 4 bytes
char *f( char *p, int n, int m )
{
return p + (n + m); // warning 679
}
By the rules of C/C++, the addition n+m is performed
independently of its context and is done at integer
precision. Any overflow is ignored even though the larger
precision of the pointer could easily accommodate the
overflow. If, on the other hand the expression were:
p+n+m, which parses as (p+n)+m, no warning would be
issued.
If the expression were p+n*m then, to suppress the
warning, a cast is needed. If long were the same size as
pointers you could use the expression:
return p + ((long) n * m);
680 Suspicious Truncation in arithmetic expression converted
to pointer -- An arithmetic expression was cast to
pointer. Moreover, the size of the pointer is greater
than the size of the expression. In computing the
expression, any overflow would be lost even though the
pointer type would be able to accommodate the lost
information. To suppress the message, cast one of the
operands to an integral type large enough to hold the
pointer. Alternatively, if you are sure there is no prob
lem you may cast the expression to an integral type before
casting to pointer. See messages 647, 776, 790 and
679.
681 Loop is not entered -- The controlling expression for a
loop (either the expression within a while clause or the
second expression within a for clause) evaluates initially
to 0 and so it appears as though the loop is never
entered.
682 sizeof applied to a parameter 'Symbol' whose type is a
sized array -- If a parameter is typed as an array it is
silently promoted to pointer. Taking the size of such an
array will actually yield the size of a pointer.
Consider, for example:
unsigned f( char a[100] ) { return sizeof(a); }
Here it looks as though function f() will return the value
100 but it will actually return the size of a pointer,
which is usually 4.
683 function 'Symbol' #define'd -- This message is issued
whenever the name of a function with some semantic
association is defined as a macro. For example:
#define strlen mystrlen
will raise this message. The problem is that the
semantics defined for strlen will then be lost. Consider
this message an alert to transfer semantics from strlen to
mystrlen, using -function(strlen, mystrlen) The message
will be issued for built-in functions (with built-in
semantics) or for user-defined semantics. The message
will not be issued if the function is defined to be a
function with a similar name but with underscores either
appended or prepended or both. For example:
#define strlen __strlen
will not produce this message. It will produce Info 828
instead.
684 Passing address of auto variable 'Symbol' into caller
space -- The address of an auto variable was passed via
assignment into a location specified by the caller to the
function. For example:
void f( int *a[] )
{
int n;
a[1] = &n;
}
Here the address of an auto variable (n) is being passed
into the second element of the array passed to the
function f. This looks suspicious because upon return the
array will contain a pointer to a variable whose lifetime
is over. It is possible that this is benign since it
could be that the caller to f() is merely passing in a
working space to be discarded upon return. If this is the
case, you can suppress the message for function f() using
the option
-efunc(684,f)
See also Warning 604.
685 Relational operator 'String,' always evaluates to 'String'
-- The first String is one of '>', '>=', '<' or '<=' and
identifies the relational operator. The second string is
one of 'True' or 'False'. The message is given when an
expression is compared to a constant and the precision of
the expression indicates that the test will always succeed or
always fail. For example,
char ch;
...
if( ch >= -128 ) ...
In this example, the precision of char ch is 8 bits signed
(assuming the fcu flag has been left in the OFF state) and
hence it has a range of values from -128 to 127 inclusive.
Hence the test is always True.
Note that, technically, ch is promoted to int before
comparing with the constant. For the purpose of this
comparison we consider only the underlying precision. As
another example, if u is an unsigned int then
if( (u & 0xFF) > 0xFF ) ...
will also raise message 685 because the expression on the
left hand side has an effective precision of 16 bits.
17.5 C Informational Messages
701 Shift left of signed quantity (int) -- Shifts are
normally accomplished on unsigned operands.
702 Shift right of signed quantity (int) -- Shifts are
normally accomplished on unsigned operands. Shifting an
int right is machine dependent (sign fill vs. zero fill).
703 Shift left of signed quantity (long) -- Shifts are
normally accomplished on unsigned operands.
704 Shift right of signed quantity (long) -- Shifts are
normally accomplished on unsigned operands. Shifting a
long right is machine dependent (sign fill vs. zero fill).
708 union initialization -- There was an attempt to
initialize the value of a union. This may not be
permitted in some older C compilers. This is because of
the apparent ambiguity: which member should be
initialized. The standard interpretation is to apply the
initialization to the first subtype of the union.
712 Loss of precision (Context) (Type to Type) -- An
assignment (or implied assignment, see Context) is being
made between two integral quantities in which the first
Type is larger than the second Type. A cast will suppress
this message.
713 Loss of precision (Context) (Type to Type) -- An
assignment (or implied assignment, see Context) is being
made from an unsigned quantity to a signed quantity, that
will result in the possible loss of one bit of integral
precision such as converting from unsigned int to int. A
cast will suppress the message.
714 Symbol 'Symbol' (Location) not referenced -- The named
external variable or external function was defined but not
referenced. This message is suppressed for unit checkout
(-u option).
715 Symbol 'Symbol' (Location) not referenced -- The named
formal parameter was not referenced.
716 while(1) ... -- A construct of the form while(1) ... was
found. Whereas this represents a constant in a context
expecting a Boolean, it may reflect a programming policy
whereby infinite loops are prefixed with this construct.
Hence it is given a separate number and has been placed in
the informational category. The more conventional form of
infinite loop prefix is for(;;)
717 do ... while(0) -- Whereas this represents a constant in
a context expecting a Boolean, this construct is probably
a deliberate attempt on the part of the programmer to
encapsulate a sequence of statements into a single
statement, and so it is given a separate error message.
[22 section 20.7] For example:
#define f(k) do {n=k; m=n+1;} while(0)
allows f(k) to be used in conditional statements as in
if(n>0) f(3);
else f(2);
Thus, if you are doing this deliberately use -e717
718 Symbol 'Symbol' undeclared, assumed to return int -- A
function was referenced without (or before) it had been
declared or defined within the current module. This is
not necessarily an error and you may want to suppress such
messages (See Chapter 14.). Note that by adding a
declaration to another module, you will not suppress this
message. It can only be suppressed by placing a
declaration within the module being processed.
719 Too many arguments for format (Integer too many) -- The
number of arguments to a function in the printf/scanf
family was more than what is specified in the format.
This message is similar to Warning 558, which alerts
users to situations in which there were too few arguments
for the format. It receives a lighter Informational
classification because the additional arguments are simply
ignored.
720 Boolean test of assignment -- An assignment was found in
a context that requires a Boolean (such as in an if() or
while() clause or as an operand to && or ||). This may be
legitimate or it could have resulted from a mistaken use
of = for ==.
721 Suspicious use of ; -- A semi-colon was found immediately
to the right of a right parenthesis in a construct of the
form if(e);. As such it may be overlooked or confused
with the use of semi-colons to terminate statements. The
message will be inhibited if the ';' is separated by at
least one blank from the ')'. Better, place it on a
separate line. See also message 548.
722 Suspicious use of ; -- A semi-colon was found immediately
to the right of a right parenthesis in a construct of the
form while(e); or for(e;e;e); As such it may be
overlooked or confused with the use of semi-colons to
terminate statements. The message will be inhibited if
the ';' is separated by at least one blank from the ')'.
Better, place it on a separate line.
723 Suspicious use of = -- A preprocessor definition began
with an = sign. For example:
#define LIMIT = 50
Was this intentional? Or was the programmer thinking of
assignment when he wrote this?
725 Expected positive indentation from Location -- The
current line was found to be aligned with, rather than
indented with respect to, the indicated line. The
indicated line corresponds to a clause introducing a
control structure and statements within its scope are
expected to be indented with respect to it. If tabs
within your program are other than 8 blanks you should use
the -t option (See Section 11.).
726 Extraneous comma ignored -- A comma followed by a
right-brace within an enumeration is not a valid ANSI
construct. The comma is ignored.
727 Symbol 'Symbol' (Location) not explicitly initialized --
The named static variable (local to a function) was not
explicitly initialized before use. The following remarks
apply to messages 728 and 729 as well as 727. By no
explicit initialization we mean that there was no
initializer present in the definition of the object, no
direct assignment to the object, and no address operator
applied to the object or, if the address of the object was
taken, it was assigned to a pointer to const. These
messages do not necessarily signal errors since the
implicit initialization for static variables is 0.
However, the messages are helpful in indicating those
variables that you had forgotten to initialize to a value.
To extract the maximum benefit from the messages we
suggest that you employ an explicit initializer for those
variables that you want to initialize to 0. For example:
static int n = 0;
For variables that will be initialized dynamically, do not
use an explicit initializer as in:
static int m;
This message will be given for any array, struct or union
if no member or element has been assigned a value.
728 Symbol 'Symbol' (Location) not explicitly initialized --
The named intra-module variable (static variable with file
scope) was not explicitly initialized. See the comments
on message 727 for more details.
729 Symbol 'Symbol' (Location) not explicitly initialized --
The named inter-module variable (external variable) was
not explicitly initialized. See the comments on message
727 for more details. This message is suppressed for unit
checkout (-u).
730 Boolean argument to function -- A Boolean was used as an
argument to a function. Was this intended? Or was the
programmer confused by a particularly complex conditional
statement. Experienced C programmers often suppress this
message. This message is given only if the associated
parameter is not declared bool.
731 Boolean argument to equal/not equal -- A Boolean was used
as an argument to == or !=. For example:
if( (a > b) == (c > d) ) ...
tests to see if the inequalities are of the same value.
This could be an error as it is an unusual use of a
Boolean (see Warnings 503 and 514) but it may also be
deliberate since this is the only way to efficiently
achieve equivalence or exclusive or. Because of this
possible use, the construct is given a relatively mild
'informational' classification. If the Boolean argument
is cast to some type, this message is not given.
732 Loss of sign (Context) (Type to Type) -- An assignment
(or implied assignment, see Context) is made from a signed
quantity to an unsigned quantity. Also, it could not be
determined that the signed quantity had no sign. For
example:
u = n; /* Info 732 */
u = 4; /* OK */
where u is unsigned and n is not, warrants a message only
for the first assignment, even though the constant 4 is
nominally a signed int.
Make sure that this is not an error (that the assigned
value is never negative) and then use a cast (to unsigned)
to remove the message.
733 Assigning address of auto variable 'Symbol' to outer scope
symbol 'Symbol' -- The address of an auto variable is
only valid within the block in which the variable is
declared. An address to such a variable has been assigned
to a variable that has a longer life expectancy. There is
an inherent danger in doing this.
734 Loss of precision (Context) (Integer bits to Integer bits)
-- An assignment is being made into an object smaller than
an int. The information being assigned is derived from
another object or combination of objects in such a way
that information could potentially be lost. The number of
bits given does not count the sign bit. For example if ch
is a char and n is an int then:
ch = n;
will trigger this message whereas:
ch = n & 1;
will not. To suppress the message a cast can be made as in:
ch = (char) n;
You may receive notices involving multiplication and shift
operators with subinteger variables. For example:
ch = ch << 2
ch = ch * ch
where, for example, ch is an unsigned char. These can be
suppressed by using the flag +fpm (precision of an
operator is bound by the maximum of its operands). See
Section 5.
735 Loss of precision (Context) (Integer bits to Integer bits)
-- An assignment (or implied assignment, see Context) is
made from a long double to a double. Using a cast will
suppress the message. The number of bits includes the
sign bit.
736 Loss of precision (Context) (Integer bits to Integer bits)
-- An assignment (or implied assignment, see Context) is
being made to a float from a value or combination of
values that appear to have higher precision than a float.
You may suppress this message by using a cast. The number
of bits includes the sign bit.
737 Loss of sign in promotion from Type to Type -- An
unsigned quantity was joined with a signed quantity in a
binary operator (or 2nd and 3rd arguments to the
conditional operator ? :) and the signed quantity is
implicitly converted to unsigned. The message will not be
given if the signed quantity is an unsigned constant, a
Boolean, or an expression involving bit manipulation. For
example,
u & ~0xFF
where u is unsigned does not draw the message even though
the operand on the right is technically a signed integer
constant. It looks enough like an unsigned to warrant not
giving the message.
This mixed mode operation could also draw Warnings 573 or
574 depending upon the operator involved.
You may suppress the message with a cast but you should
first determine whether the signed value could ever be
negative or whether the unsigned value can fit within the
constraints of a signed quantity.
738 Symbol 'Symbol' (Location) not explicitly initialized --
The named static local variable was not initialized before
being passed to a function whose corresponding parameter
is declared as pointer to const. Is this an error or is
the programmer relying on the default initialization of 0
for all static items. By employing an explicit
initializer you will suppress this message. See also
message numbers 727 and 603.
739 Trigraph Sequence 'String' in literal (Quiet Change) --
The indicated Trigraph (three-character) sequence was
found within a string. This trigraph reduces to a single
character according to the ANSI standard. This represents
a "Quiet Change" from the past where the sequence was not
treated as exceptional. If you had no intention of
mapping these characters into a single character you may
precede the initial '?' with a backslash. If you are
aware of the convention and you intend that the Trigraph
be converted you should suppress this informational
message.
740 Unusual pointer cast (incompatible indirect types) -- A
cast is being made to convert one pointer to another such
that neither of the pointers is a generic pointer (neither
is pointer to char, unsigned char, or void) and the
indirect types are truly different. The message will not
be given if the indirect types differ merely in signedness
(e.g., pointer to unsigned versus pointer to int) or in
qualification (e.g., pointer to const int versus pointer
to int). The message will also not be given if one of the
indirect types is a union.
The main purpose of this message is to report possible
problems for machines in which pointer to char is rendered
differently from pointer to word. Consider casting a
pointer to pointer to char to a pointer to pointer to
word. The indirect bit pattern remains unchanged.
A second reason is to identify those pointer casts in
which the indirect type doesn't seem to have the proper
bit pattern such as casting from a pointer to int to a
pointer to double.
If you are not interested in running on machines in which
char pointers are fundamentally different from other
pointers then you may want to suppress this message. You
can also suppress this message by first casting to char
pointer or to void pointer but this is only recommended if
the underlying semantics are right.
741 Unusual pointer cast (function qualification) -- A cast
is being made between two pointers such that their
indirect types differ in one of the Microsoft qualifiers:
pascal, fortran, cdecl and interrupt. If this is not an
error you may cast to a more neutral pointer first such as
a void *.
742 Multiple character constant -- A character constant was
found that contained multiple characters, e.g., 'ab'.
This is legal C but the numeric value of the constant is
implementation defined. It may be safe to suppress this
message because, if more characters are provided than what
can fit in an int, message number 25 is given.
743 Negative character constant -- A character constant was
specified whose value is some negative integer. For
example, on machines where a byte is 8 bits, the character
constant 'xFF' is flagged because its value (according to
the ANSI standard) is -1 (its type is int). Note that its
value is not 0xFF.
744 switch statement has no default -- A switch statement has
no section labeled default:. Was this an oversight? It
is standard practice in many programming groups to always
have a default: case. This can lead to better (and
earlier) error detection. One way to suppress this
message is by introducing a vacuous default: break;
statement. If you think this adds too much overhead to
your program, think again. In all cases tested so far,
the introduction of this statement added absolutely
nothing to the overall length of code. If you accompany
the vacuous statement with a suitable comment, your code
will at least be more readable.
This message is not given if the control expression is an
enumerated type. In this case, all enumerated constants
are expected to be represented by case statements, else
787 will be issued.
745 function 'Name' has no explicit type or class, int assumed
-- A function declaration or definition contained no
explicit type. Was this deliberate? If the flag fdr
(deduce return mode, see Section 5.5 Flag Options) is
turned on, this message is suppressed.
746 call to function 'Name' not made in the presence of a
prototype -- A call to a function is not made in the
presence of a prototype. This does not mean that
PC-lint/FlexeLint is unaware of any prototype; it means
that a prototype is not in a position for a compiler to
see it. If you have not adopted a strict prototyping
convention you will want to suppress this message with
-e746.
747 Significant prototype coercion (Context) Type to Type --
The type specified in the prototype differed from the type
provided as an argument in some significant way. Usually
the two types are arithmetic of differing sizes or one is
float and the other integral. This is flagged because if
the program were to be translated by a compiler that does
not support prototype conversion, the conversion would not
be performed. See also Section 17.6 C Elective Notes 917
and 918.
748 Symbol 'Symbol' (Location) is a register variable used
with setjmp -- The named variable is a register variable
and is used within a function that calls upon setjmp.
When a subsequent longjmp is issued the values of register
variables may be unpredictable. If this error is not sup
pressed for this variable, the variable is marked as
uninitialized at this point in the program.
More information on messages 749-769 can be found in Section 11.8
Weak Definials.
749 local enumeration constant 'Symbol' (Location) not
referenced -- A member (name provided as Symbol) of an
enum was defined in a module but was not otherwise used
within that module. A 'local' member is one that is not
defined in a header file. Compare with messages 754 and
769.
750 local macro 'Symbol' (Location) not referenced -- A
'local' macro is one that is not defined in a header file.
The macro is not referenced throughout the module in which
it is defined.
751 local typedef 'Symbol' (Location) not referenced -- A
'local' typedef symbol is one that is not defined in any
header file. It may have file scope or block scope but it
was not used through its scope.
752 local declarator 'Symbol' (Location) not referenced -- A
'local' declarator symbol is one declared in a declaration
appearing in the module file itself as opposed to a header
file. The symbol may have file scope or may have block
scope. But it wasn't referenced.
753 local struct, union or enum tag 'Symbol' (Location) not
referenced -- A 'local' tag is one not defined in a
header file. Since its definition appeared, why was it
not used? Use of a tag is implied by the use of any of
its members.
754 local structure member 'Symbol' (Location) not referenced
-- A member (name provided as Symbol) of a struct or union
was defined in a module but was not otherwise used within
that module. A 'local' member is one that is not defined
in a header file. See message 768.
755 global macro 'Symbol' (Location) not referenced -- A
'global' macro is one defined in a header file. This
message is given for macros defined in non-library
headers. The macro is not used in any of the modules
comprising the program. This message is suppressed for
unit checkout (-u option). See Section 11.
756 global typedef 'Symbol' (Location) not referenced -- This
message is given for a typedef symbol declared in a
non-library header file. The symbol is not used in any of
the modules comprising a program. This message is
suppressed for unit checkout (-u option).
757 global declarator 'Symbol' (Location) not referenced --
This message is given for objects that have been declared
in non-library header files and that have not been used in
any module comprising the program being checked. The
message is suppressed for unit checkout (-u).
758 global struct, union or enum tag 'Symbol' (Location) not
referenced -- This message is given for struct, union and
enum tags that have been defined in non-library header
files and that have not been used in any module comprising
the program. The message is suppressed for unit checkout
(-u).
759 header declaration for symbol 'Symbol' (Location) could be
moved from header to module -- This message is given for
declarations, within non-library header files, that are
not referenced outside the defining module. Hence, it can
be moved inside the module and thereby 'lighten the load'
on all modules using the header. This message is only
given when more than one module is being linted.
760 Redundant macro 'Symbol' defined identically at Location
-- The given macro was defined earlier (location given) in
the same way and is hence redundant.
761 Redundant typedef 'Symbol' previously declared at Location
-- A typedef symbol has been typedefed earlier at the
given location. Although the declarations are consistent
you should probably remove the second.
762 Redundantly declared symbol 'Symbol' previously declared
at Location -- A declaration for the given symbol was
found to be consistent with an earlier declaration in the
same scope. This declaration adds nothing new and it can
be removed.
763 Redundant declaration for symbol 'Symbol' previously
declared at Location -- A tag for a struct, union or enum
was defined twice in the same module (consistently). The
second one can be removed.
764 switch statement does not have a case -- A switch
statement has been found that does not have a case
statement associated with it (it may or may not have a
default statement). This is normally a useless construct.
765 external 'Symbol' (Location) could be made static -- An
external symbol was referenced in only one module. It was
not declared static (and its type is not qualified with
the Microsoft keyword __export). Some programmers like to
make static every symbol they can, because this lightens
the load on the linker. It also represents good
documentation. On the other hand, you may want the symbol
to remain external because debuggers often work only on
external names. It's possible, using macros, to have the
best of both worlds; see Section 11.8.3 staticable.
766 Include of header file FileName not used in module String
-- The named header file was directly #include'd in the
named module but the #include can be removed because it
was not used in processing the named module or in any
header included by the module. It contained no macro,
typedef, struct, union or enum tag or component, or
declaration referenced by the module. One of the reasons
a particular #include can be removed is because it had
been included by an earlier header file. Warning 537 can
be used to detect such cases. See also Info messages
964, 966 and Section 11.8.1 Unused Headers.
767 macro 'Symbol' was defined differently in another module
(Location) -- Two macros processed in two different
modules had inconsistent definitions.
768 global struct member 'Symbol' (Location) not referenced
-- A member (name provided as Symbol) of a struct or union
appeared in a non-library header file but was not used in
any module comprising the program. This message is
suppressed for unit checkout. Since struct's may be
replicated in storage, finding an unused member can pay
handsome storage dividends. However, many structures
merely reflect an agreed upon convention for accessing
storage and for any one program many members are unused.
In this case, receiving this message can be a nuisance.
One convenient way to avoid unwanted messages (other than
the usual -e and -esym) is to always place such structures
in library header files. Alternatively, you can place the
struct within a ++flb ... --flb sandwich to force it to be
considered library.
769 global enumeration constant 'Symbol' (Location) not
referenced -- A member (name provided as Symbol) of an
enum appeared in a non-library header file but was not
used in any module comprising the program. This message
is suppressed for unit checkout. There are reasons why a
programmer may occasionally want to retain an unused enum
and for this reason this message is distinguished from
768 (unused member). See message 768 for ways of
selectively suppressing this message.
770 tag 'Symbol' defined identically at Location -- The
struct, union, or enum tag Symbol was defined identically
in different locations (usually two different files).
This is not an error but it is not necessarily good
programming practice either. It is better to place common
definitions of this kind in a header file where they can
be shared among several modules. If you do this, you will
not get this message. Note that if the tag is defined
differently in different scopes, you will receive warning
631 rather than this message.
771 Symbol 'Symbol' (Location) conceivably not initialized --
The named symbol, declared at Location, was initialized in
the main portion of a control loop (while, for, or do) and
subsequently used outside the loop. If it is possible for
the main body of the loop to not be fully executed, then
the given symbol would remain uninitialized resulting in
an error.
PC-lint/FlexeLint does not do a great job of evaluating
expressions and hence may not recognize that a loop is
executed at least once. This is particularly true after
initializing an array. Satisfy yourself that the loop is
executed and then suppress the message. You may wish to
suppress the message globally with -e771 or just for
specific symbols using -esym. Don't forget that a simple
assignment statement may be all that's needed to suppress
the message. See Section 9.
772 Symbol 'Symbol' (Location) conceivably not initialized --
The address of the named Symbol was passed to a function
expecting to receive a pointer to a const item. This
requires the Symbol to have been initialized. See Warning
603 for an explanation of the dangers of such a construct.
See Informational message 771 for an explanation of
"conceivably not initialized."
773 Expression-like macro 'Symbol' not parenthesized -- A
macro that appeared to be an expression contained
unparenthesized binary operators and therefore may result
in unexpected associations when used with other operators.
For example,
#define A B + 1
may be used later in the context:
f( A * 2 );
with the surprising result that B+2 gets passed to f and
not the (B+1)*2 Corrective action is to define A as:
#define A (B + 1)
Lowest precedence binary operators are not reported upon.
Thus:
#define A s.x
does not elicit this message because this case does not
seem to represent a problem. Also, unparenthesized unary
operators (including casts) do not generate this message.
Information about such unparenthesized parameters can be
found by enabling Elective Note 973. [22 section 20.5]
774 Boolean within 'String' always evaluates to [True/False]
-- The indicated clause (String is one of if, while or for
(2nd expression)) has an argument that appears to always
evaluate to either 'True' or 'False' (as indicated in the
message). Information is gleaned from a variety of
sources including prior assignment statements and
initializers. Compare this with message 506, which is
based on testing constants or combinations of constants.
Also compare with the Elective Note 944, which can
sometimes provide more detailed information. See Section 9.
775 non-negative quantity cannot be less than zero -- A
non-negative quantity is being compared for being <=0.
This is a little suspicious since a non-negative quantity
can be equal to 0 but never less than 0. The non-negative
quantity may be of type unsigned or may have been promoted
from an unsigned type or may have been judged not to have
a sign by virtue of it having been AND'ed with a quantity
known not to have a sign bit an enum that may not be
negative, etc. See also Warning 568.
776 Possible truncation of addition -- An int expression
(signed or unsigned) involving addition or subtraction is
converted to long implicitly or explicitly. Moreover, the
precision of a long is greater than that of int. If an
overflow occurred, information would be lost. Either cast
one of the operands to some form of long or cast the
result to some form of int.
See Warning 647 for a further description and an example
of this kind of error. See also messages 790 and 942.
777 Testing float's for equality -- This message is issued
when the operands of operators == and != are some form of
floating type (float, double, or long double). Testing
for equality between two floating point quantities is
suspect because of round-off error and the lack of perfect
representation of fractions. If your numerical algorithm
calls for such testing turn the message off. The message
is suppressed when one of the operands can be represented
exactly, such as 0 or 13.5.
778 Constant expression evaluates to 0 in operation: String
-- A constant expression involving addition, subtraction,
multiplication, shifting, or negation resulted in a 0.
This could be a purposeful computation but could also have
been unintended. If this is intentional, suppress the
message. If one of the operands is 0, Elective Note 941
may be issued rather than a 778.
779 String constant in comparison operator: Operator -- A
string constant appeared as an argument to a comparison
operator. For example:
if( s == "abc" ) ...
This is usually an error. Did the programmer intend to
use strcmp? It certainly looks suspicious. At the very
least, any such comparison is bound to be
machine-dependent. If you cast the string constant, the
message is suppressed.
780 Vacuous array element -- A declaration of an array looks
suspicious because the array element is an array of 0
dimension. For example:
extern int a[][];
extern int a[10][];
will both emit this message but
extern int a[][10];
will not. In the latter case, proper array accessing will
take place even though the outermost dimension is missing.
If extern were omitted, the construct would be given a
more serious error message.
781 Inconsistent use of tag 'Symbol' conflicts with Location
-- A tag specified as a union, struct, or enum was
specified as some other type in another module (location
given by Location). For example, if tag is specified as
union in one module and is specified as struct in the
current module you will get this message. See also
Warning 407.
782 Line exceeds Integer characters -- An internal limit on
the size of the input buffer has been reached. The
message contains the maximum permissible size. This does
not necessarily mean that the input will be processed
erroneously. Additional characters will be read on a
subsequent read. However the line sequence numbers
reported on messages will be incorrect.
783 Line does not end with new-line -- This message is issued
when an input line is not terminated by a new-line or when
a NUL character appears within an input line. When input
lines are read, an fgets is used. A strlen call is made
to determine the number of characters read. If the
new-line character is not seen at the presumed end, this
message is issued. If your editor is in the habit of not
appending new-lines onto the end of the last line of the
file then suppress this message. Otherwise, examine the
file for NUL characters and eliminate them.
784 Nul character truncated from string -- During
initialization of an array with a string constant there
was not enough room to hold the trailing NUL character.
For example:
char a[3] = "abc";
would evoke such a message. This may not be an error
since the easiest way to do this initialization is in the
manner indicated. It is more convenient than:
char a[3] = { 'a', 'b', 'c' };
On the other hand, if it really is an error it may be
especially difficult to find.
785 Too few initializers for aggregate -- The number of
initializers in a brace-enclosed initializer was less than
the number of items in the aggregate. Default
initialization is taken. An exception is made with the
initializer {0}. This is given a separate message number
in the Elective Note category ( 943). It is normally
considered to be simply a stylized way of initializing all
members to 0.
786 String concatenation within initializer -- Although it is
perfectly 'legal' to concatenate string constants within
an initializer, this is a frequent source of error.
Consider:
char *s[] = { "abc" "def" };
Did the programmer intend to have an array of two strings
but forget the comma separator? Or was a single string
intended?
787 enum constant 'Symbol' not used within switch -- A switch
expression is an enumerated type and at least one of the
enumerated constants was not present as a case label.
Moreover, no default case was provided.
788 enum constant 'Symbol' not used within defaulted switch
-- A switch expression is an enumerated type and at least
one of the enumerated constants was not present as a case
label. However, unlike Info 787, a default case was
provided. This is a mild form of the case reported by
Info 787. The user may thus elect to inhibit this mild
form while retaining Info 787.
789 Assigning address of auto variable 'Symbol' to static --
The address of an auto variable (Symbol) is being assigned
to a static variable. This is dangerous because the
static variable will persist after return from the
function in which the auto is declared but the auto will
be, in theory, gone. This can prove to be among the
hardest bugs to find. If you have one of these, make cer
tain there is no error and use -esym to suppress the
message for a particular variable.
790 Suspicious truncation, integral to float -- This message
is issued when it appears that there may have been an
unintended loss of information during an operation
involving integrals, the result of which is later
converted to a floating point quantity. The operations
that are scrutinized and reported upon by this message
are: shift left and multiplication. Addition and
subtraction are covered by Elective Note 942. See also
messages 647 and 776.
791 unusual option sequence -- A temporary message
suppression option (one having the form: !e...) followed
a regular option. Was this intended?
792 void cast of void expression -- A void expression has
been cast to void. Was this intended?
793 ANSI limit of 'String' 'Name' exceeded -- Some ANSI limit
has been exceeded. These limits are described in Section
2.2.4.1 of the ANSI C Standard. Programs exceeding these
limits are not considered maximally portable. However,
they may work for individual compilers.
Many large programs exceed the ANSI limit of 511 external
identifiers. This will result in message 793 "ANSI limit
of 511 'external identifiers' exceeded". It may not be
obvious how to inhibit this message for identifiers while
leaving other limits in a reportable state. The second
parameter of the message is designated Name and so the
-esym may be used. Because the symbol contains a blank,
quotes must be used. The option becomes:
-"esym(793,external identifiers)"
794 Conceivable use of null pointer 'Symbol' in [left/right]
argument to operator 'String' Reference -- From
information gleaned from earlier statements it is
conceivable that a null pointer (a pointer whose value is
0) can be used in a context where null pointers are
inappropriate. In the case of binary operators one of the
words 'left' or 'right' is used to designate which operand
is null. Symbol identifies the pointer variable that may
be NULL. This is similar to messages 413 and 613 and
differs from them in that the likelihood is not as great.
For example:
int *p = 0;
int i;
for( i = 0; i < n; i++ )
p = &a[i];
*p = 0;
If the body of the for loop is never taken then p remains
null.
795 Conceivable division by 0 -- In a division or modulus
operation the division is deduced to be conceivably 0.
See Section 9.2 Value Tracking for the meaning of
"conceivable".
796 Conceivable access of out-of-bounds pointer ('Integer'
beyond end of data) by operator 'String' -- An
out-of-bounds pointer may conceivably have been accessed.
See message 415 for a description of the parameters
Integer and String. For example:
int a[10];
int j = 100;
for( i = 0; i < n; i++ )
j = n;
a[j] = 0;
Here, the access to a[j] is flagged because it is
conceivable that the for loop is not executed leaving the
unacceptable index of 100 in variable j. This message is
similar to messages 415 and 661 but differing from them
by the degree of probability.
797 Conceivable creation of out-of-bounds pointer ('Integer'
beyond end of data) by operator 'String' -- An
out-of-bounds pointer is potentially being created. See
message 415 for a description of the parameters Integer
and String. See message 796 for an example of how a
probability can be considered 'conceivable'. See also
message 416 and/or Section 9.2 Value Tracking) for a
description of the difference between pointer 'creation'
and pointer 'access'.
798 Redundant character 'Char' -- The indicated character
char is redundant and can be eliminated from the input
source. A typical example is a backslash on a line by
itself.
799 numerical constant 'Integer' larger than unsigned long --
An integral constant was found to be larger than the
largest value allowed for unsigned long quantities. By
default, an unsigned long is 4 bytes but can be
respecified via the option -sl#. If the long long type is
permitted (see option +fll) this message is automatically
suppressed. See also message 417.
801 Use of goto is deprecated -- A goto was detected. Use of
the goto is not considered good programming practice by
most authors and its use is normally discouraged. There
are a few cases where the goto can be effectively employed
but often these can be rewritten just as effectively
without the goto. The use of goto's can have a
devastating effect on the structure of large functions
creating a mass of spaghetti-like confusion. For this
reason its use has been banned in many venues.
802 Conceivably passing a null pointer to function 'Symbol',
Context Reference -- A NULL pointer is conceivably being
passed to a function identified by Symbol. The argument
in question is given by Context. The function is either a
library function designed not to receive a NULL pointer or
a user function dubbed so via the option -function. See
Section 10. See Section 9.2 Value Tracking for the
meaning of 'conceivable'.
803 Conceivable data overrun for function 'Symbol', argument
Integer exceeds argument Integer Reference -- This
message is for data transfer functions such as memcpy,
strcpy, fgets, etc. when the size indicated by the first
cited argument (or arguments) can conceivably exceed the
size of the buffer area cited by the second. The message
may also be issued for user functions via the -function
option. See Section 10. See Section 9.2 Value Tracking
for the meaning of 'conceivable'.
804 Conceivable access beyond array for function 'Symbol',
argument Integer exceeds Integer Reference -- This
message is issued for several library functions (such as
fwrite, memcmp, etc) wherein there is conceivably an
attempt to access more data than exist. For example, if
the length of data specified in the fwrite call can exceed
the size of the data specified. The function is specified
by Symbol and the arguments are identified by argument
number. See also Section 10.1 Function Mimicry (function)
and Section 9.2 Value Tracking.
805 Expected L"..." to initialize wide char string -- An
initializer for a wide character array or pointer did not
use a preceding 'L'. For example:
wchar_t a[] = "abc";
was found whereas
wchar_t a[] = L"abc":
was expected.
806 Small bit field is signed rather than unsigned -- A small
bit field (less than an int wide) was found and the base
type is signed rather than unsigned. Since the most
significant bit is a sign bit this practice can produce
surprising results. For example,
struct { int b:1; } s;
s.b = 1;
if( s.b > 0 ) /* should succeed but actually fails */
...
807 Conceivably passing to function 'Symbol' a negative value
(Integer), Context Reference -- An integral value that
may conceivably be negative is being passed to a function
that is expecting only positive values for a particular
argument. The message contains the name of the function
(Symbol), the questionable value (Integer) and the
argument number (Context). The function may be a standard
library function designed to accept only positive values
such as malloc or memcpy (third argument), or may have
been identified by the user as such through the -function
or -sem options. See message 422 for an example and
further explanation.
808 No explicit type given symbol 'Symbol' given, assumed int
-- An explicit type was missing in a declaration. Unlike
Warning 601, the declaration may have been accompanied by
a storage class or modifier (qualifier) or both. For
example:
extern f(void);
will draw message 808. Had the extern not been present, a
601 would have been raised.
The keywords unsigned, signed, short and long are taken to
be explicit type specifiers even though int is implicitly
assumed as a base.
809 Possible return of address of auto through variable
'Symbol' -- The value held by a pointer variable may have
been the address of an auto variable. It is normally
incorrect to return the address of an item on the stack
because the portion of the stack allocated to the
returning function is subject to being obliterated after
return.
810 Arithmetic modification of custodial variable 'Symbol' --
We define the custodial variable as that variable directly
receiving the result of a malloc or new or equivalent
call. It is inappropriate to modify such a variable
because it must ultimately be free'ed or delete'ed. You
should first make a copy of the custodial pointer and then
modify the copy. The copy is known as an alias.
811 Possible deallocation of pointer alias -- A free or a
delete was applied to a pointer that did not appear to be
the custodial variable of the storage that had been
allocated. Please refer to message 810 for the
definition of 'custodial variable'. Deleting an alias
pointer is bad because it can result in deleting the same
area twice. This can cause strange behavior at
unpredictable times. Always try to identify the custodial
pointer as opposed to copies (or aliases) of it. Then
deallocate storage through the custodial pointer. Modify
only the alias pointers.
812 static variable 'Symbol' has size 'Integer' -- The amount
of storage for a static symbol has reached or exceeded a
value that was specified in a -size option ( See Section 5.).
813 auto variable 'Symbol' in function 'Symbol' has size
'Integer' -- The amount of storage for an auto symbol has
reached or exceeded a value that was specified in a -size
option ( See Section 5.).
815 Arithmetic modification of unsaved pointer -- An
allocation expression (malloc, calloc, new) is not
immediately assigned to a variable but is used as an
operand in some expression. This would make it difficult
to free the allocated storage. For example:
p = new X[n] + 2;
will elicit this message. A preferred sequence is:
q = new X[n];
p = q+2;
In this way the storage may be freed via the custodial
pointer q.
Another example of a statement that will yield this
message is:
p = new (char *) [n];
This is a gruesome blunder on the part of the programmer.
It does NOT allocate an array of pointers as a novice
might think. It is parsed as:
p = (new (char *)) [n];
which represents an allocation of a single pointer
followed by an index into this 'array' of one pointer.
816 Non-ANSI format specification -- A non-standard format
specifier was found in a format-processing function such
as printf or scanf. Such a specifier could be unique to a
particular compiler or could be a de facto standard but is
not ANSI.
817 Conceivably negative subscript (Integer) in operator
'String' -- An integer whose value was conceivably
negative was added to an array or to a pointer to an
allocated area (allocated by malloc, operator new, etc.)
This message is not given for pointers whose origin is
unknown since a negative subscript is in general legal.
The addition could have occurred as part of a subscript
operation or as part of a pointer arithmetic operation.
The operator is denoted by String. The value of the
integer is given by Integer.
818 Pointer parameter 'Symbol' (Location) could be declared
ptr to const -- As an example:
int f( int *p ) { return *p; }
can be redeclared as:
int f( const int *p ) { return *p; }
Declaring a parameter a pointer to const offers advantages
that a mere pointer does not. In particular, you can pass
to such a parameter the address of a const data item. In
addition it can offer better documentation.
Other situations in which a const can be added to a
declaration are covered in messages 952, 953, 954 and 1764.
820 Boolean test of a parenthesized assignment -- A Boolean
test was made on the result of an assignment and,
moreover, the assignment was parenthesized. For example:
if ( (a = b) ) ... // Info 820
will draw this informational whereas
if ( a = b ) ... // Info 720
(i.e. the unparenthesized case) will, instead, draw Info
720. We, of course, do not count the outer parentheses,
required by the language, that always accompany the if
clause.
The reason for partitioning the messages in this fashion
is to allow the programmer to adopt the convention,
advanced by some compilers (in particular gcc), of always
placing a redundant set of parentheses around any
assignment that is to be tested. In this case you can
suppress Info 820 (via -e820) while still enabling Info 720.
821 Right hand side of assignment not parenthesized -- An
assignment operator was found having one of the following
forms:
a = b || c
a = b && c
a = b ? c : d
Moreover, the assignment appeared in a context where a
value was being obtained. For example:
f( a = b ? c : d );
The reader of such code could easily confuse the
assignment for a test for equality. To eliminate any such
doubts we suggest parenthesizing the right hand side as in:
f( a = (b ? c : d) );
825 control flows into case/default without -fallthrough
comment -- A common programming mistake is to forget a
break statement between case statements of a switch. For
example:
case 'a': a = 0;
case 'b': a++;
Is the fall through deliberate or is this a bug? To
signal that this is intentional use the -fallthrough
option within a lint comment as in:
case 'a': a = 0;
//lint -fallthrough
case 'b': a++;
This message is similar to Warning 616 ("control flows
into case/default") and is intended to provide a stricter
alternative. Warning 616 is suppressed by any comment
appearing at the point of the fallthrough. Thus, an
accidental omission of a break can go undetected by the
insertion of a neutral comment. This can be hazardous to
well-commented programs.
826 Suspicious pointer-to-pointer conversion (area too small)
-- A pointer was converted into another either implicitly
or explicitly. The area pointed to by the destination
pointer is larger than the area that was designated by the
source pointer. For example:
long *f( char *p ) { return (long *) p; }
827 Loop not reachable -- A loop structure (for, while, or
do) could not be reached. Was this an oversight? It may
be that the body of the loop has a labeled statement and
that the plan of the programmer is to jump into the middle
of the loop through that label. It is for this reason
that we give an Informational message and not the Warning
( 527) that we would normally deliver for an unreachable
statement. But please note that jumping into a loop is a
questionable practice in any regard.
828 Semantics of function 'Name' copied to function 'Name' --
A function with built-in semantics or user-defined
semantics was #define'd to be some other function with a
similar name formed by prepending or appending
underscores. For example:
#define strcmp(a,b) __strcmp__(a,b)
will cause Info 828 to be issued. As the message
indicates, the semantics will be automatically transferred
to the new function.
829 A +headerwarn option was previously issued for header
'Symbol' -- Some coding standards discourage or even
prohibit the use of certain header files. PC-lint can
guard against their use if we by activating the lint
option +headerwarn(Symbol). Later, if the file is used,
we will then issue this message.
830 Location cited in prior message -- Message 830 is a
vehicle to convey in 'canonical form' the location
information embedded within some other message. For
example, consider the (somewhat simplified) message:
file x.c line 37: Declaration for 'x' conflicts
with line 22
This contains the location ("line 22") embedded in the
text of the message. Embedded location information is not
normally understood by editors and IDE's (Interactive
Development Environments), which can only position to the
nominal location (line 37 in this example). By adding
this additional message with the nominal location of line
22 the user can, by stepping to the next message, see what
the 'conflict' is all about.
831 Reference cited in prior message -- Message 831 is
similar to message 830 in that it is a vehicle to convey
in 'canonical form' location information embedded within
some other message. In the case of Info 831 the
information is Reference information. This is a sequence
of 1 or more locations that support a particular message.
For example, consider the (somewhat simplified) message:
file y.c line 701: Possible divide by 0 [Reference: file
z.c lines 22, 23]
Accompanying this message will be two Info 831 messages,
one for each of the references cited in the message.
Without this it would be a relatively tedious matter to
locate each one of the references to determine just why
there is a potential divide by 0. With these additional
messages, editors and IDE's can automatically position the
focus of editing to the nominal locations of the message.
832 Parameter 'Symbol' not explicitly declared, int assumed
-- In an old-style function definition a parameter was not
explicitly declared. To illustrate:
void f( n, m )
int n;
{ ...
This is an example of an old-style function definition
with n and m the parameters. n is explicitly declared and
m is allowed to default to int. An 832 will be issued for m.
833 Symbol 'Symbol' is typed differently (String) in another
module, compare with Location -- Two objects, functions or
definials are typed differently in two different modules.
This is a case where the difference is legal but may cause
confusion on the part of program maintenance.
834 Operator 'Name' followed by operator 'Name' is confusing.
Use parentheses. -- Some combinations of operators seem to
be confusing. For example:
a = b - c - d;
a = b - c + d;
a = b / c / d;
a = b / c * d;
tend to befuddle the reader. To reduce confusion we
recommend using parentheses to make the association of
these operators explicit. For example:
a = (b - c) - d;
a = (b - c) + d;
a = (b / c) / d;
a = (b / c) * d;
in place of the above.
17.6 C Elective Notes
Messages in the 900 level are termed "elective" because they are
not normally on. They must be explicitly turned on with an
option of the form +e9... or -w4. Messages in the range
910-919 involve implicit conversions. Messages in the range
920-930 involve explicit conversions (casts).
900 Successful completion, 'Integer' messages produced --
This message exists to provide some way of ensuring that
an output message is always produced, even if there are no
other messages. This is required for some windowing
systems. For this purpose use the option +e900.
909 Implicit conversion from Type to bool -- A non-bool was
tested as a Boolean. For example, in the following
function:
int f(int n)
{
if( n ) return n;
else return 0;
}
the programmer tests 'n' directly rather than using an
explicit Boolean expression such as 'n != 0'. Some shops
prefer the explicit test.
910 Implicit conversion (Context) from 0 to pointer -- A
pointer was assigned (or initialized) with a 0. Some
programmers prefer other conventions such as NULL or nil.
This message will help such programmers root out cavalier
uses of 0. This is relatively easy in C since you can
define NULL as follows:
#define NULL (void *)0
However, in C++, a void* cannot be assigned to other
pointers without a cast. Instead, assuming that NULL is
defined to be 0, use the option:
--emacro((910),NULL)
This will inhibit message 910 in expressions using NULL.
This method will also work in C.
Both methods assume that you expressly turn on this
message with a +e910 or equivalent.
911 Implicit expression promotion from Type to Type -- Notes
whenever a sub-integer expression such as a char, short,
enum, or bit-field is promoted to int for the purpose of
participating in some arithmetic operation or function call.
912 Implicit binary conversion from Type to Type -- Notes
whenever a binary operation (other than assignment)
requires a type balancing. A smaller range type is
promoted to a larger range type. For example: 3 + 5.5
will trigger such a message because int is converted to
double.
913 Implicit adjustment of expected argument type from Type to
Type -- Notes whenever an old-style function definition
contains a sub-integer or float type. For example:
int f( ch, x ) char ch; float x; { ...
contains two 913 adjustments.
914 Implicit adjustment of function return value from Type to
Type -- Notes whenever the function return value is
implicitly adjusted. This message is given only for
functions returning arrays.
915 Implicit conversion (Context) Type to Type -- Notes
whenever an assignment, initialization or return implies
an arithmetic conversion (Context specifies which).
916 Implicit pointer assignment conversion (Context) -- Notes
whenever an assignment, initialization or return implies
an implicit pointer conversion (Context specifies which).
917 Prototype coercion (Context) Type to Type -- Notes
whenever an implicit arithmetic conversion takes place as
the result of a prototype. For example:
double sqrt(double);
... sqrt(3); ...
will elicit this message because 3 is quietly converted to
double.
918 Prototype coercion (Context) of pointers -- Notes
whenever a pointer is implicitly converted because of a
prototype. Because of prototype conversion, near pointers
will otherwise be silently mapped into far pointers. far
pointers mapped into near pointers also generate message
619.
919 Implicit conversion (Context) Type to Type -- A lower
precision quantity was assigned to a higher precision
variable as when an int is assigned to a double.
920 Cast from Type to void -- A cast is being made from the
given type to void.
921 Cast from Type to Type -- A cast is being made from one
integral type to another.
922 Cast from Type to Type -- A cast is being made to or from
one of the floating types (float, double, long double).
923 Cast from Type to Type -- A cast is being made either
from a pointer to a non-pointer or from a non-pointer to a
pointer.
924 Cast from Type to Type -- A cast is being made from a
struct or a union. If the cast is not to a compatible
struct or union error 69 is issued.
925 Cast from pointer to pointer -- A cast is being made to
convert one pointer to another such that one of the
pointers is a pointer to void. Such conversions are considered
harmless and normally do not even need a cast.
926 Cast from pointer to pointer -- A cast is being made to
convert a char pointer to a char pointer (one or both of
the char's may be unsigned). This is considered a 'safe'
cast.
927 Cast from pointer to pointer -- A cast is being made to
convert a char (or unsigned char) pointer to a non-char
pointer. char pointers are sometimes implemented
differently from other pointers and there could be an
information loss in such a conversion.
928 Cast from pointer to pointer -- A cast is being made from
a non-char pointer to a char pointer. This is generally
considered to be a 'safe' conversion.
929 Cast from pointer to pointer -- A cast is being made to
convert one pointer to another that does not fall into one
of the classifications described in 925 through 928
above. This could be nonportable on machines that
distinguish between pointer to char and pointer to word.
Consider casting a pointer to pointer to char to a pointer
to pointer to word. The indirect bit pattern remains
unchanged.
930 Cast from Type to Type -- A cast is being made to or from
an enumeration type.
931 Both sides have side effects -- Indicates when both sides
of an expression have side-effects. An example is n++ +
f(). This is normally benign. The really troublesome
cases such as n++ + n are caught via Warning 564.
932 Passing near pointer to library function 'Symbol'
(Context) -- A source of error in Windows programming is
to pass a near pointer to a library function (See Chapter
6.). If the library is a DLL library, then in supplying
the missing segment, the library would assume its own data
segment, which would probably be wrong. See also messages
933 and 934.
933 Passing near pointer to far function (Context) -- A
source of error in Windows programming is to pass a near
pointer to a DLL function. Most Microsoft functions in
DLLs are declared with the far modifier. Hence this can
be tentatively used as a discriminant to decide that a
pointer is too short. An advantage that this Note has
over 932 is that it can catch functions designated only
by pointer. Also you may be using libraries that are not
DLLs and that share the same DS segment. In this case,
932 may produce too many superfluous messages. See also
message 934.
934 taking address of near auto variable 'Symbol' (Context)
-- A source of error in writing DLL libraries is that the
stack segment may be different from the data segment. In
taking the address of a near data object only the offset
is obtained. In supplying the missing segment, the
compiler would assume the data segment, which could be
wrong. See also messages 932 and 933.
935 int within struct -- This Note helps to locate
non-portable data items within struct's. If instead of
containing int's and unsigned int's, a struct were to
contain short's and long's then the data would be more
portable across machines and memory models. Note that bit
fields and union's do not get complaints.
936 old-style function definition for function 'Symbol' -- An
"old-style" function definition is one in which the types
are not included between parentheses. Only names are
provided between parentheses with the type information
following the right parenthesis. This is the only style
allowed by K&R.
937 old-style function declaration for function 'Symbol' --
An "old-style" function declaration is one without type
information for its arguments.
938 parameter 'Symbol' not explicitly declared -- In an
"old-style" function definition it is possible to let a
function parameter default to int by simply not providing
a separate declaration for it.
939 return type defaults to int for function 'Symbol' -- A
function was declared without an explicit return type. If
no explicit storage class is given, then Informational
745 is also given provided the Deduce Return mode flag
(fdr) is off. This is meant to catch all cases.
940 omitted braces within an initializer -- An initializer
for a subaggregate does not have braces. For example:
int a[2][2] = { 1, 2, 3, 4 };
This is legal C but may violate local programming
standards. The worst violations are covered by Warning 651.
941 Result 0 due to operand(s) equaling 0 in operation
'String' -- The result of a constant evaluation is 0
owing to one of the operands of a binary operation being
0. This is less severe than Info 778 wherein neither
operand is 0. For example, expression (2&1) yields a 778
whereas expression (2&0) yields a 941.
942 Possibly truncated addition promoted to float -- An
integral expression (signed or unsigned) involving
addition or subtraction is converted to a floating point
number. If an overflow occurred, information would be
lost. See also messages 647, 776 and 790.
943 Too few initializers for aggregate -- The initializer {0}
was used to initialize an aggregate of more than one item.
Since this is a very common thing to do it is given a
separate message number, which is normally suppressed.
See 785 for more flagrant abuses.
944 [left/right/] argument for operator 'String' always
evaluates to [True/False] -- The indicated operator
(given by String has an argument that appears to always
evaluate to either 'True' or 'False' (as indicated in the
message). This is given for Boolean operators (||and &&
and for Unary operator !) and information is gleaned from
a variety of sources including prior assignment statements
and initializers. Compare this with message 506, which
is based on testing constants or combinations of constants.
945 Undefined struct used with extern -- Some compilers
refuse to process declarations of the form:
extern struct X s;
where struct X is not yet defined. This note can alert a
programmer porting to such platforms.
946 Relational or subtract operator applied to pointers -- A
relational operator (one of >, >=, <, <=) or the subtract
operator has been applied to a pair of pointers. The
reason this is of note is that when large model pointers
are compared (in one of the four ways above) or
subtracted, only the offset portion of the pointers is
subject to the arithmetic. It is presumed that the
segment portion is the same. If this presumption is not
accurate then disaster looms. By enabling this message
you can focus in on the potential trouble spots.
947 Subtract operator applied to pointers -- An expression of
the form p - q was found where both p and q are pointers.
This is of special importance in cases where the maximum
pointer can overflow the type that holds pointer
differences. For example, suppose that the maximum
pointer is 3 Gigabytes -1, and that pointer differences
are represented by a long, where the maximum long is 2
Gigabytes -1. Note that both of these quantities fit
within a 32 bit word. Then subtracting a small pointer
from a very large pointer will produce an apparent
negative value in the long representing the pointer
difference. Conversely, subtracting a very large pointer
from a small pointer can produce a positive quantity.
The alert reader will note that a potential problem exists
whenever the size of the type of a pointer difference
equals the size of a pointer. But the problem doesn't
usually manifest itself since the highest pointer values
are usually less than what a pointer could theoretically
hold. For this reason, the message cannot be given
automatically based on scalar types and hence has been
made an Elective Note.
Compare this Note with that of 946, which was designed
for a slightly different pointer difference problem.
950 Non-ISO/ANSI reserved word or construct: 'Symbol' --
Symbol is either a reserved word that is non-ISO/ANSI or a
construct (such as the // form of comment in a C module).
This Elective Note is enabled automatically by the -A
option. If these messages are occurring in a compiler or
library header file over which you have no control, you
may want to use the option -elib(950). If the reserved
word is one you want to completely disable, then use the
option -rw(Word).
951 Pointer to incomplete type 'Symbol' employed in operation
-- A pointer to an incomplete type (for example, struct X
where struct X has not yet been defined in the current
module) was employed in an assignment or in a comparison
(for equality) operator. For example, suppose a module
consisted only of the following function:
struct A * f(struct A *p )
{
return p;
}
Since struct A had not been defined, this message will be
issued. Such employment is permitted by the standard but
is not permitted by all C compilers. If you want to
deploy your application to the maximum number of platforms
you should enable this Elective Note.
952 Parameter 'Symbol' (Location) could be declared const --
A parameter is not modified by a function. For example:
int f( char *p, int n ) { return *p = n; }
can be redeclared as:
int f( char * const p, const int n ) { return *p = n; }
There are few advantages to declaring an unchanging
parameter a const. It signals to the person reading the
code that a parameter is unchanging, but, in the estimate
of most, reduces legibility. For this reason the message
has been given an Elective Note status.
However, there is a style of programming that encourages
declaring parameters const. For the above example, this
style would declare f as
int f( char * p, int n);
and would use the const qualifier only in the definition.
Note that the two forms are compatible according to the
standard. The declaration is considered the interface
specification where const does not matter. The const's do
matter in the definition of the function, which is
considered the implementation. Message 952 could be used
to support this style.
Marking a parameter as const does not affect the type of
argument that can be passed to the parameter. In
particular, it does not mean that only const arguments may
be passed. This is in contrast to declaring a parameter
as pointer to const or reference to const. For these
situations, Informational messages are issued ( 818 and
1764 respectively) and these do affect the kinds of
arguments that may be passed. See also messages 953 and 954.
953 Variable 'Symbol' (Location) could be declared as const
-- A local variable (either static or auto) is initialized
but never modified thereafter. Such a variable could be
declared const. One advantage in making such a
declaration is that it can furnish a clue to the program
reader that the variable is unchanging. In the case of
static data it can mean that the data is ROM'able. Other
situations in which a const can be added to a declaration
are covered in messages 818, 952, 954 and 1764.
954 Pointer variable 'Symbol' (Location) could be declared as
pointing to a const -- The data pointed to by a pointer
is never changed (at least not through that pointer). It
may therefore be better, or at least more descriptive, if
the variable were typed pointer to const. For example:
{
char *p = "abc";
for( ; *p; p++ ) print(*p);
}
can be redeclared as:
{
const char *p = "abc";
for( ; *p; p++ ) print(*p);
}
It is interesting to contrast this situation with that of
pointer parameters. The latter is given Informational
status ( 818) because it has an effect of enhancing the
set of pointers that can be passed into a function. Other
situations in which a const can be added to a declaration
are covered in messages 952, 953 and 1764.
955 Parameter name missing from prototype for function
'Symbol' -- In a function declaration a parameter name is
missing. For example:
void f(int);
will raise this message. This is perfectly legal but
misses an opportunity to instruct the user of a library
routine on the nature of the parameter. For example:
void f(int count);
would presumably be more meaningful. [27, Rule 34].
This message is not given for function definitions, only
function declarations.
956 Non const, non volatile static or external variable
'Symbol' -- This check has been advocated by programmers
whose applications are multi-threaded. Software that
contains modifiable data of static duration is often
non-reentrant. That is, two or more threads cannot run
the code concurrently. By 'static duration' we mean
variables declared static or variables declared external
to any function. For example:
int count = 0;
void bump() { count++; }
void get_count() { return count; }
If the purpose is to obtain a count of all the bump()'s by
a given thread then this program clearly will not do since
the global variable count sums up the bump()'s from all
the threads. Moreover, if the purpose of the code is to
obtain a count of all bump()'s by all threads, it still
may contain a subtle error (depending on the compiler and
the machine). If it is possible to interrupt a thread
between the access of count and the subsequent store, then
two threads that are bump()'ing at the same time, may
register an increase in the count by just one.
Please note that not all code is intended to be
re-entrant. In fact most programs are not designed that
way and so this Elective Note need not be enabled for the
majority of programs. If the program is intended to be
re-entrant, all uses of non-const static variables should
be examined carefully for non-reentrant properties.
957 Function 'Symbol' defined without a prototype in scope --
A function was defined without a prototype in scope. It
is usually good practice to declare prototypes for all
functions in header files and have those header files
checked against the definitions of the function to assure
that they match.
If you are linting all the files of your project together
such cross checking will be done in the natural course of
things. For this reason this message has been given a
relatively low urgency of Elective Note.
958 Padding of Integer byte(s) is required to align member on
Integer byte boundary -- This message is given whenever
padding is necessary within a struct to achieve a required
member alignment. Consider:
struct A { char c; int n; };
Assuming that int must be aligned on a 4-byte boundary and
assuming the size of a char to be 1, then this message
will be issued indicating that there will be a padding of
3 bytes.
The alignment requirements vary with the compiler, the
machine and, sometimes, compiler options. When separately
compiled programs need to share data at the binary level
it helps to remove any artificially created padding from
any of the structures that may be shared.
959 struct size (Integer bytes) is not an even multiple of the
maximum member alignment (Integer bytes) -- The alignment