> >> 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 _______________________________________________ Bug-glpk mailing list Bug-glpk@gnu.org https://lists.gnu.org/mailman/listinfo/bug-glpk