Re: Suppressing sanitizer in sha256.c
On 04.04.2018 21:12, Paul Eggert wrote: > On 04/04/2018 12:45 AM, Tim Rühsen wrote: >> reducing false positives > would be of great help to reduce time >> spent into securing code that > > uses gnulib. > Yes, and Gnulib tries to strike a balance here. For Gnulib headers, we > try harder to pacify compilers even if we think their warnings are > misguided. This particular bug report was about a .c file, though, and > for that it's reasonable to suggest that you not use the compile-time > option that enables this flag when compiling Gnulib code, as it is > more trouble than it's worth in Gnulib code. > Thanks, good to know. Regards, Tim
Re: Suppressing sanitizer in sha256.c
On 04/04/2018 12:45 AM, Tim Rühsen wrote: reducing false positives > would be of great help to reduce time spent into securing code that > uses gnulib. Yes, and Gnulib tries to strike a balance here. For Gnulib headers, we try harder to pacify compilers even if we think their warnings are misguided. This particular bug report was about a .c file, though, and for that it's reasonable to suggest that you not use the compile-time option that enables this flag when compiling Gnulib code, as it is more trouble than it's worth in Gnulib code.
Re: Suppressing sanitizer in sha256.c
On 04/03/2018 11:45 PM, Bruno Haible wrote: > Eric Blake wrote: >> What are the clang developers using as their justification >> for this warning? > > Quoting the clang documentation [1]: > > "-fsanitize=unsigned-integer-overflow: >Unsigned integer overflows. Note that unlike signed integer overflow, >unsigned integer is not undefined behavior. However, while it has well- >defined semantics, it is often unintentional, so UBSan offers to catch it." > > Bruno > > [1] https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html Thanks for looking into it. To squeeze out as many potential bugs from my applications, I turn all sanitizer options on. Then I reduce false positives by tagging the code parts / functions. A bit like deduction. The bad thing with clang is that I can't tag the calling function (in my application) but have to set the attribute for the function that triggers (in gnulib). Gnulib is made to serve app/lib developers. And reducing false positives would be of great help to reduce time spent into securing code that uses gnulib. But I understand if you deny to that on the gnulib's side - you would possibly open a can of worms. Regards, Tim signature.asc Description: OpenPGP digital signature
Re: Suppressing sanitizer in sha256.c
Eric Blake wrote: > What are the clang developers using as their justification > for this warning? Quoting the clang documentation [1]: "-fsanitize=unsigned-integer-overflow: Unsigned integer overflows. Note that unlike signed integer overflow, unsigned integer is not undefined behavior. However, while it has well- defined semantics, it is often unintentional, so UBSan offers to catch it." Bruno [1] https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
Re: Suppressing sanitizer in sha256.c
On 04/03/2018 04:03 PM, Paul Eggert wrote: > On 04/03/2018 01:47 PM, Tim Rühsen wrote: >> This is expected behavior but still it rings the 'alarm bell'. > > My kneejerk reaction is that the code has well-defined behavior and I'd > rather that developers didn't use -fsanitize=unsigned-integer-overflow. > For Gnulib, that flag is more trouble than it's worth. I can see the validity of claiming that signed integer overflow is undefined behavior, but I thought the C standard was pretty clear that unsigned integer overflow is well-defined and performs modulo arithmetic. What are the clang developers using as their justification for this warning? Paul is probably correct that the warning is a bug in clang, if they can't back up their warning with an actual quote from the C standard. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: Suppressing sanitizer in sha256.c
On 04/03/2018 01:47 PM, Tim Rühsen wrote: This is expected behavior but still it rings the 'alarm bell'. My kneejerk reaction is that the code has well-defined behavior and I'd rather that developers didn't use -fsanitize=unsigned-integer-overflow. For Gnulib, that flag is more trouble than it's worth.
