2

I am doing static code analysis (Using Gimpel PC- Lint) of my source code. In code analysis, i am getting a warning 'Suspicious Truncation in arithmetic expression combining with pointer'.

Here is the what analysis report says::

source\interp.cpp(142): error 679: (Warning -- Suspicious Truncation in arithmetic expression combining with pointer)

    py[ulIndex] = y[ulIndex+1] - y[ulIndex];

Here py, y are dynamic array of data type double with same size but still the warning is coming up in code analysis for the above line.

Can anyone help me to figure out this?

Thanks in advance.

Jaffa
  • 12,442
  • 4
  • 49
  • 101
Yogi
  • 83
  • 1
  • 10

3 Answers3

2

It may be because your adding an int to an unsigned long with ulIndex+1 Try 

py[ulIndex] = y[ulIndex+UL1]-y[ulIndex];

Or it could depend on how you've defined py and y arrays.

ChrisBD
  • 9,104
  • 3
  • 22
  • 35
0

It could be because you are using an unsigned expression as an array index (or in the resulting pointer arithmetic), which IIRC should be a signed expression for most C implementations.

The C standards do not define whether the index expression should be signed or unsigned, but most (all?) current C implementations used signed indexes.

EDIT:

There is a message reference for your checker here. I think that the checker warns on the implicit cast from unsigned int to int, which may incur information loss. Try adding an explicit cast to int and see if the message changes/goes away.

thkala
  • 84,049
  • 23
  • 157
  • 201
  • It's a C++ source file (.cpp), and C++ explicitly supports both signed and unsigned indices. You can mix them freely, even for a single array. I.e. `a[int(5)] + a[unsigned(6)]` is valid. – MSalters Oct 10 '11 at 09:29
  • @MSalters: Interesting! What happens with the C++ implementation in the case of `a[0x80000000]` on a 32-bit architecture? – thkala Oct 10 '11 at 09:33
  • Well, since that's just INT_MAX, the literal has type `int`. Assuming the array is big enough, that just returns `*(a+0x7fffffff)`. On a 16 bit system, `0x7fffffff` would have type `long`, and it would still return `*(a+0x7fffffff)` (assuming the 16 bit system does support arrays that big) – MSalters Oct 10 '11 at 09:36
  • [sneak edit there] When 0x80000000 is bigger than INT_MAX, it's an literal with type `unsigned int`. No difference at all, really: you get `*(a+0x80000000)`, again assuming that `a` is declared sufficiently big to start with. – MSalters Oct 10 '11 at 09:38
  • @MSalters: `a` is a pointer though, is it not? Pointer size is fixed and pointer arithmetic is signed on most current systems. I believe that it would still overflow and you would get something unexpected: instead of a memory location "after" `a`, you'd get one "before". – thkala Oct 10 '11 at 09:42
  • On those systems, you wouldn't be able to declare an array that big. It's required that array elements are ordered such that `&a[i] < &a[j]` if and only if `i – MSalters Oct 10 '11 at 09:47
0

The correct type for an array index is size_t. You're getting a warning because size_t(ulIndex+1) may be zero, instead of size_t(ulIndex)+1

Community
  • 1
  • 1
MSalters
  • 173,980
  • 10
  • 155
  • 350