Boost logo

Boost :

Subject: Re: [boost] [array] Invalid data: accessing 'elems'
From: Niels Dekker - address until 2010-10-10 (niels_address_until_2010-10-10_at_[hidden])
Date: 2010-08-04 03:51:10


On 2010-08-02-Mon 18:29, Mateusz Loskot wrote:
> I compile a small test program using Visual C++ 10.0 (Visual Studio 2010
> Premium) with static code analysis turned on (option /analyze):
>
> #include <boost/array.hpp>
> int main()
> {
> typedef int T; // short, char, etc.
> boost::array<T, 2> x;
> T a = x[0];
> }
>
> and whichever integer type I use for T, the analyser throws
> similar reports every time:
  ...
> 1>g:\dev\boost\_svn\trunk\boost\array.hpp(111): warning C6385: Invalid
> data: accessing 'elems', the readable size is '8' bytes, but '12' bytes
> might be read: Lines: 110, 111

FYI, I get the very same warning on Visual Studio 2008. Interestingly,
the warning doesn't appear when the array size is 1. Note also that the
warning is also gone when BOOST_ASSERT call inside
boost::array::operator[] is commented out:

   reference operator[](size_type i)
   {
      // Skipped: BOOST_ASSERT( i < N && "out of range" );
      return elems[i];
   }

> Shall I report a ticket?

Do you have a proposed fix? I can think of a few possible options:

* Add #pragma warning(disable: 6385) to boost/array.hpp

* Or add an __analysis_assume call to boost::array::operator[]:

   reference operator[](size_type i)
   {
      BOOST_ASSERT( i < N && "out of range" );
      __analysis_assume(i < N);
      return elems[i];
   }

* Or add __analysis_assume(expr) to the BOOST_ASSERT(expr) macro
itself... (boost/assert.hpp)?

What do you think?

BTW, the following compiler bug report seems related: Microsoft Visual
Studio bug report ID 281033, "False warning C6385 when a function result
is used as an array index",
http://connect.microsoft.com/VisualStudio/feedback/details/281033/

HTH, Niels

-- 
Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Scientific programmer at LKEB, Leiden University Medical Center

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk