dengwirda / robust-predicate

Robust geometric predicates without the agonising pain.
Other
15 stars 2 forks source link

warning: array subscript 1 is above array bounds of 'const mp_float::expansion<1>::real_type [1] during compilation #4

Open thomasp85 opened 5 months ago

thomasp85 commented 5 months ago

Hi - thanks for this package!

When I compile my code which uses your library I get

warning: array subscript 1 is above array bounds of 'const mp_float::expansion<1>::real_type [1]

There is a couple of places in the code where mp::expansion< 1 > are created but mp_float seems to assume 2 elements are always present in a lot of places. I don't feel safe proposing a fix to this as this library is already a bit above my C++ level

dengwirda commented 5 months ago

Thanks for the feedback @thomasp85. What compiler / settings are you using though? Currently I'm not seeing these warnings with g++ or clang++.

thomasp85 commented 5 months ago

Using mingw g++.exe v12.3.0 g++ -std=gnu++17 -DNDEBUG -pedantic -O2 -Wall -mfpmath=sse -msse2 -mstackrealign

thomasp85 commented 5 months ago

I only see the warning there, not on Mac and Linux

dengwirda commented 5 months ago

Ah, mingw --- thanks for the info. Checking back through the code, the float expansions should be compile-time protected by various static_asserts etc, so any out-of-bounds issues should fail on build. I suspect what's going on here could just be a spurious warning from mingw... Nonetheless, I'll leave this open and try to spin up a windows VM somehow and investigate.

thomasp85 commented 5 months ago

Could you point me to the places where it is protected (unless it is scattered all over). I know I'll have to make my case when I submit my package to the official repo

edit: Nevermind, I think I found them all. Indeed it seems like an oversight in mingw

thomasp85 commented 5 months ago

Some more info from the error (don't know why I didn't lead with this)

In member function 'const mp_float::expansion<N>::real_type& mp_float::expansion<N>::operator[](indx_type) const [with long long unsigned int N = 1]',
    inlined from 'void mp_float::fast_expansion_sub_zeroelim(const expansion<NE>&, const expansion<NF>&, expansion<NH>&) [with long long unsigned int NE = 4; long long unsigned int NF = 1; long long unsigned int NH = 5]' at robust_predicate/expansion/mp_float.hpp:509:26:
robust_predicate/expansion/mp_float.hpp:151:29: warning: array subscript 1 is above array bounds of 'const mp_float::expansion<1>::real_type [1]' {aka 'const double [1]'} [-Warray-bounds]
  151 |         return ( this->_xdat[_ii] ) ;
      |                ~~~~~~~~~~~~~^~~~~~~
robust_predicate/expansion/mp_float.hpp: In function 'void mp_float::fast_expansion_sub_zeroelim(const expansion<NE>&, const expansion<NF>&, expansion<NH>&) [with long long unsigned int NE = 4; long long unsigned int NF = 1; long long unsigned int NH = 5]':
robust_predicate/expansion/mp_float.hpp:98:32: note: while referencing 'mp_float::expansion<1>::_xdat'
   98 |     real_type                  _xdat [ N ] ;
      |        
thomasp85 commented 5 months ago

Digging in (fully acknowledging it's above my head), it does seem that

https://github.com/dengwirda/robust-predicate/blob/cba45db1b0dd66c3ee693be0f05b33675ae4b4b3/expansion/mp_float.hpp#L495-L509

allows _ff and _ee indexing to move past it's length because _fi is tested against _ff._xlen but then pre-incremented during indexing. There is perhaps some logic that prevent this from happening but it is likely that mingw can't disentangle that?

HansBrende commented 1 week ago

@thomasp85 this looks like the same issue I've seen before. See my comment here for an explanation:

https://github.com/danshapero/predicates/issues/14#issuecomment-2105303956