Re: [Bug-glpk] -Wstringop-overflow in function _glp_wclique1

[Andrew Makhorin]

> >> compiling GLPK 4.63 on arm64 with gcc 7.2 gives the following warning:
> >>
> >> misc/wclique1.c: In function ‘_glp_wclique1’:
> >> misc/wclique1.c:121:7: warning: ‘memset’: specified size between
> >> 18446744071562067968 and 18446744073709551615 exceeds maximum object
> >> size 9223372036854775807 [-Wstringop-overflow=]
> >>        memset(&skip[1], 0, sizeof(char) * n);
> >>        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> misc/wclique1.c:123:7: warning: ‘memset’: specified size between
> >> 18446744071562067968 and 18446744073709551615 exceeds maximum object
> >> size 9223372036854775807 [-Wstringop-overflow=]
> >>        memset(&d_flag[1], 0, sizeof(char) * n);
> >>        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>
> > 
> > Please ignore this warning message. The compiler makes a wrong
> > conclusion that n declared as int can be negative and being converted to
> > size_t which is unsigned long can result in a huge value (for example,
> > (size_t)-1 results in 2^64-1). This however cannot happen due to a check
> > xassert(n >= 0); in line 90.
> 
> Compiling should not generate any warnings. 

It depends on the compiler used. My own ANSI C89 compiler issues no
warnings on compiling glpk (except zlib, which uses old-style
functions). On the other hand, MSVC, for example, may complain even if
you assign int to short because this is "unsafe" (perhaps such warnings
are intended for MS programmers :).

> Many packages are compiled
> with -Werror. 

Simply don't use this option.

> So this should be fixed in the code.

No, I don't think so. Glpk code is valid and legitimate, so there is no
need to change it just to make a particular compiler happy.

> 
> > 
> >> It can be avoided by first converting to unsigned int:
> >>
> >> 120       /* initially all vertices are unmarked */
> >> 121       memset(&skip[1], 0, sizeof(char) * (unsigned int)n);
> >> 122       /* clear flags of all vertices */
> >> 123       memset(&d_flag[1], 0, sizeof(char) * (unsigned int)n);
> >>
> > 
> > Then on a 32-bit platform there will be a similar message, because
> > converting -1 to unsigned int gives 2^32-1.
> 
> I have tested on arm 32bit. Yes you are right. Yet still the problem
> should be fixed and not ignored.
> 


Best regards,

Andrew Makhorin