[PATCH] Sanitize printf functions

Kostya Serebryany kcc at google.com
Thu Jan 9 01:34:58 PST 2014


On Thu, Jan 9, 2014 at 1:09 PM, Yury Gribov <tetra2005 at gmail.com> wrote:

>
>
> ================
> Comment at: asan/lit_tests/TestCases/printf-2.c:2
> @@ +1,3 @@
> +// RUN: %clang_asan -O2 %s -o %t
> +// RUN: not %t 2>&1 | FileCheck %s
> +
> ----------------
> Yury Gribov wrote:
> > Yury Gribov wrote:
> > > Kostya Serebryany wrote:
> > > > please make these tests run in 3 modes:
> > > >   ASAN_OPTIONS=check_printf=0
> > > >   ASAN_OPTIONS=check_printf=1
> > > >   ASAN_OPTIONS=""
> > > >
> > > > we need to test that the flag affects the behavior and that it's
> default value is what we expect it to be.
> > > >
> > > > (use FileCheck --check-prefix=CHECK-ON and --check-prefix=CHECK-OFF)
> > > Ok.
> > BTW how do you suggest the check_printf=0 case? In my understanding
> we'll have UB with absolutely unpredictable behavior...
> > That's not that bad.
> > If you allocate a heap block using asan's allocator,
> > the behavior of an uncheck-ed out-of-bounds read is quite predictable
>
> I tend to agree but e.g. GCC team tends to reject tests that trigger UB.
> Also things like this tend to be rather unstable with respect to
> glibc/kernel versions.
>

If you run a test under asan and dereference a[4001] (where 'a' is a heap
allocated block of 4000 bytes) glibc or kernel are not involved.
Such test is not supposed to run w/o asan, where it would indeed be bad.


>
> I'll do this if you're adamant though.
>

In LLVM -- yes, please.
GCC has a different test suite anyway.




>
>
>
> http://llvm-reviews.chandlerc.com/D2480
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140109/fa5a72fa/attachment.html>


More information about the llvm-commits mailing list