Review and Fix Invalid Use of Standard Library Routine Checks

This topic describes how to systematically review the results of an Invalid use of standard library routine check in Polyspace^® Code Prover™.

Follow one or more of these steps until you determine a fix for the Invalid use of standard library routine check. For a description of the check and code examples, see Invalid use of standard library routine.

Sometimes, especially for an orange check, you can determine that the check does not represent a real error but a Polyspace assumption that is not true for your code. If you can use an analysis option to relax the assumption, rerun the verification using that option. Otherwise, you can add a comment and justification in your result or code.

For the general workflow that applies to all checks, see Interpret Code Prover Results in Polyspace Desktop User Interface or Interpret Code Prover Results in Polyspace Access Web Interface (Polyspace Access).

Step 1: Interpret Check Information

Select the check on the Results List pane. View further information about the check on the Result Details pane. The check is red or orange because of invalid function arguments.

The cause of a red or orange check depends on the standard library function that you use. The following table shows the possible causes for some of the commonly used functions.

Function	Cause of Red or Orange Check
islower, isdigit, and other character-handling functions in ctype.h	The value of the argument can be outside the range allowed for an unsigned char variable. Note that you can use the macro EOF as argument.
Functions in math.h	The software checks for multiple kinds of errors in sequence. The software performs each check only for those execution paths where the previous check passes. Some examples are given below. For more information and a list of functions, see Invalid Use of Standard Library Floating Point Routines.
	sqrt	The value of the argument can be negative.
	pow	The first argument can be negative while the second argument is a non-integer.
	exp, exp2, or the hyperbolic functions	The argument can be so large that the result exceeds the value allowed for a double.
	log	The argument can be zero or negative.
	asin or acos	The argument can be outside the range [-1,1].
	tan	The argument can have the value HALF_PI.
	acosh	The argument can be less than 1.
	atanh	The argument can be greater than 1 or less than -1.
fprintf, fscanf, and other file handling functions	The file pointer argument can be non-readable. For example, it can be NULL.
Functions that take string arguments	The string argument can be an invalid string. For example, it does not end with a terminating '\0'.
memmove or memcpy	The third argument of this function specifies the number of bytes to copy from the second to the first argument. This number can exceed the memory allocated to the first or second argument.

Step 2: Trace Check to Polyspace Assumption

See if you can trace the orange check to a Polyspace assumption that occurs earlier in the code. If the assumption does not hold true in your case, add a comment or justification in your result or code. See Address Results in Polyspace User Interface Through Bug Fixes or Justifications or Address Results in Polyspace Access Through Bug Fixes or Justifications (Polyspace Access).

For instance, you obtain a value from an undefined function and perform the sqrt operation on it. Then:

1. Polyspace assumes that the function can return a negative value.

2. Therefore, the software produces an orange Invalid Use of Standard Library Routine check on the sqrt function call.

3. If you know that the function returns a positive value, to avoid the orange, you can specify a constraint on the return value of your function. See Code Prover Assumptions About Stubbed Functions. Alternately, add a comment and justification describing why you did not change your code.

For more information, see Code Prover Analysis Assumptions.