[lmi] Invalid pointer-pair?

[Greg Chicares]

[Here's an ASan complaint that goes away if I use std::array
instead of std::vector const. That's a good change anyway,
so I'll commit it. The stream of consciousness leading up to
that discovery might be interesting, as it seems to indicate
an ASan false positive AFAICT.]

ASan with
  
-fsanitize=address,undefined,leak,pointer-compare,pointer-subtract,float-divide-by-zero,float-cast-overflow,bounds-strict
and
  export 
ASAN_OPTIONS=detect_leaks=0:detect_invalid_pointer_pairs=2:detect_invalid_pointer_pairs=2:strict_string_checks=1:\
    
detect_stack_use_after_return=1:check_initialization_order=1:strict_init_order=1
flags this line:
  /opt/lmi/src/lmi/irc7702_tables_test.cpp:656
as anomalous:

==820578==ERROR: AddressSanitizer: invalid-pointer-pair: 0x7f4c8d37ad00 
0x7f4c8d37a080
    #0 0x563f0fcc3485 in std::iterator_traits<cf_data const*>::difference_type 
std::__
distance<cf_data const*>(cf_data const*, cf_data const*, 
std::random_access_iterator_tag) /us
r/include/c++/11/bits/stl_iterator_base_funcs.h:104
    #1 0x563f0fcc3485 in std::iterator_traits<cf_data const*>::difference_type 
std::di
stance<cf_data const*>(cf_data const*, cf_data const*) 
/usr/include/c++/11/bits/stl_iterator_
base_funcs.h:141
    #2 0x563f0fcc3485 in void std::vector<cf_data, std::allocator<cf_data> 
>::_M_range
nclude/c++/11/bits/stl_vector.h:1580
    #3 0x563f0fcc3485 in std::vector<cf_data, std::allocator<cf_data> 
>::vector(std::initializer_list<cf_data>, std::allocator<cf_data> const&) 
/usr/include/c++/11/bits/stl_vector.h:629
    #4 0x563f0fb7ce72 in __static_initialization_and_destruction_0 
/opt/lmi/src/lmi/irc7702_tables_test.cpp:656
    #5 0x563f0fe41904 in __libc_csu_init 
(/opt/lmi/gcc_x86_64-pc-linux-gnu/build/ubsan/irc7702_tables_test+0x736904)
    #6 0x7f4c902a577c in __libc_start_main ../csu/libc-start.c:279
    #7 0x563f0fb7e379 in _start 
(/opt/lmi/gcc_x86_64-pc-linux-gnu/build/ubsan/irc7702_tables_test+0x473379)

But the code beginning on that line
  /opt/lmi/src/lmi/irc7702_tables_test.cpp:656
is simply:

static std::vector<cf_data> const olcf_1980_cso_endt_100 =
{{0.00000, 1                     , 0                     , 0.06996023573869656} 
// 0
,{0.00000, 0.9615384615384615    , 0                     , 0.07275864516824443} 
// 1
[...snip many similar lines...]
,{1.00000, 1.3667620786298768e-05, 1.3141943063748814e-05, 0.9806435265780128 } 
// 99
};

AFAICS, this direct initialization is a "best practice".
Can that code really be objectionable in any way? This ASAN
diagnostic persists if I remove "static", and also if I both
remove "static" and put the defining-declaration inside an
unnamed namespace.

The complaint about (#0):
  std::distance<cf_data const*>(cf_data const*, cf_data const*)
refers to code generated by gcc: I never explicitly form any
such pointer.

If I edit the source and remove the lines snipped above,
then ASan accepts this (modified) definition, but issues
the same diagnostics as above for the similar definition
that follows. But the size of the raw data is only
  4000 = 5 rows * 100 columns * 8 bytes per 'double'
which would be okay even for a 1990s "small model" build,
and of course nowadays this object isn't really big.

It's not a function, so it can't be worked around with an
attribute such as:

  #if defined LMI_GCC || defined LMI_CLANG
  __attribute__((no_sanitize("invalid-pointer-pair")))
  #endif // defined LMI_GCC || defined LMI_CLANG

because those attributes can be used only on functions.

Wait...let's make it a std::array instead. Now it passes
all those ASan checks. That's actually a desirable change
in its own right, so it's not just a silly workaround.