[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debian-med-packaging] Bug#853568: No idea how to fix abs arguments in nanopolish



Am Donnerstag, den 31.08.2017, 21:00 -0700 schrieb Walter Landry:
> Andreas Tille <andreas@an3as.eu> wrote:
> > Hi,
> > 
> > to fix bug #853568 I tried a patch (gcc-7.patch) to fix abs()
> > arguments
> > in nanopolish[1] but I have no idea how to deal with this:
> > 
> > ...
> > g++ -o src/hmm/nanopolish_pore_model_set.o -c -g -O2 -fdebug-
> > prefix-map=/build/nanopolish-0.5.0=. -fstack-protector-strong
> > -Wformat -Werror=format-security -g -O3 -std=c++11 -fopenmp -Wdate-
> > t
> > src/common/nanopolish_variant.cpp: In function
> > 'std::vector<Variant> extract_variants(const string&, const
> > string&)':
> > src/common/nanopolish_variant.cpp:32:69: error: call of overloaded
> > 'abs(std::__cxx11::basic_string<char>::size_type)' is ambiguous
> >      size_t difference = std::abs(reference.size() -
> > haplotype.size());
> 
> The result of subtracting two size_t's is still a size_t, which is
> unsigned.  So you need to cast it to a signed type.  The correct type
> is ptrdiff_t.
> 
>   http://en.cppreference.com/w/cpp/types/ptrdiff_t
> 
> The line then becomes
> 
>   size_t difference =
> std::abs(static_cast<ptrdiff_t>(reference.size() -
> haplotype.size()));

Casting the difference may result in undefined behavior. Consider the
case 

   reference.size() == 1
   haplotype.size() == 2 

then 

   reference.size() - haplotype.size() 

will be 0xFFFFFFFF (on 32 bit), and how this is casted to a signed type
is implementation dependent (i.e. it is not guaranteed that this simply
wraps to -1, it may also raise a trap because of integer overflow). 

It would be better to avoid the cast altogether by doing something like

   size_t difference = reference.size() > haplotype.size() ? 
                       reference.size() - haplotype.size() : 
                       haplotype.size() - reference.size(); 


or cast both values before doing the subtraction.

Best, 
Gert 


Reply to: