Mahesh Attarde via llvm-dev
2017-Nov-04 19:01 UTC
[llvm-dev] [Sanitizer] Sanitizer does not identify violation
Hello fellas,
Recently i was working on bug, which is simplified as follow.
==================================================================================================================Code:
#include<iostream>
int thisShallError(int b[10]){
int gaurdTop = 0xF0F0;
int c[16] = {0};
int gaurdDown[16];
gaurdDown[0] = 0x0F0F;
return c[16] | b[11];
}
int main(){
int mb[32]={0};
mb[11] = 0xF0F0;
std::cout<<std::hex << thisShallError(mb);
return 0;
}
Warning:
4 : <source>:4:9: warning: unused variable 'gaurdTop'
[-Wunused-variable] <https://godbolt.org/#>
int gaurdTop = 0xF0F0;
^
8 : <source>:8:12: warning: array index 16 is past the end of the
array (which contains 16 elements) [-Warray-bounds]
<https://godbolt.org/#>
return c[16] | b[11];
^ ~~
5 : <source>:5:5: note: array 'c' declared here
<https://godbolt.org/#>
int c[16] = {0};
^
2 warnings generated.
Compiler exited with result code 0
==============================================================================
Things to note here.
1. variable b's size is know at compile time and i was expecting error just
like c [third warning]
2. thisShallError accepts size of array as 10 but it is clearly declared
with 32. Should we do something. [Given fact that Array will decay to
pointer but sanitizer may warn, if possible]
I want to confirm if this is bug or not,sanitizer has no false positive
rule scenario??, will happy to patch it myself :)
Thanks
Mahesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171105/3c6c34de/attachment.html>
Brian Cain via llvm-dev
2017-Nov-04 19:32 UTC
[llvm-dev] [Sanitizer] Sanitizer does not identify violation
Mahesh, First, to clarify: the term "sanitizer" refers to a set of dynamic techniques for finding bugs and it does not intersect at all with these statically-detected compiler warnings. The AddressSanitizer would detect out-of-bounds issues like these at runtime and in my experience false negatives and false positives are very rare. Though since the access of b[11] is actually in-bounds, it would not trigger. This behavior is likely by design and not considered a bug. So, regarding the warnings: If you had declared the parameter with "static" qualifying the size, *and* you had passed an array smaller than the size indicated, that would result in another warning from the caller. Note that this is a C99 feature that is not present in C++. Here's a demo showing the resulting warnings from clang when using that feature: https://godbolt.org/g/48NnME Absent the "static" qualifier for the size, there's no real restriction from the language regarding the access of b[11] in the thisShallError() func beyond it failing to meet an implicit API. On Sat, Nov 4, 2017 at 2:01 PM, Mahesh Attarde via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hello fellas, > Recently i was working on bug, which is simplified as follow. > > > ===========================================================> ======================================================> Code: > #include<iostream> > > int thisShallError(int b[10]){ > int gaurdTop = 0xF0F0; > int c[16] = {0}; > int gaurdDown[16]; > gaurdDown[0] = 0x0F0F; > return c[16] | b[11]; > } > > int main(){ > int mb[32]={0}; > mb[11] = 0xF0F0; > std::cout<<std::hex << thisShallError(mb); > return 0; > } > > > Warning: > > 4 : <source>:4:9: warning: unused variable 'gaurdTop' [-Wunused-variable] <https://godbolt.org/#> > int gaurdTop = 0xF0F0; > ^ > 8 : <source>:8:12: warning: array index 16 is past the end of the array (which contains 16 elements) [-Warray-bounds] <https://godbolt.org/#> > return c[16] | b[11]; > ^ ~~ > 5 : <source>:5:5: note: array 'c' declared here <https://godbolt.org/#> > int c[16] = {0}; > ^ > 2 warnings generated. > Compiler exited with result code 0 > > ===========================================================> ==================> > > Things to note here. > 1. variable b's size is know at compile time and i was expecting error > just like c [third warning] > 2. thisShallError accepts size of array as 10 but it is clearly declared > with 32. Should we do something. [Given fact that Array will decay to > pointer but sanitizer may warn, if possible] > > I want to confirm if this is bug or not,sanitizer has no false positive > rule scenario??, will happy to patch it myself :) > > Thanks > Mahesh > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-- -Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171104/4dbae874/attachment.html>