[PATCH] D54527: Add new interceptor for strtonum(3)

Kamil Rytarowski via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 6 12:33:53 PST 2018


krytarowski marked an inline comment as done.
krytarowski added inline comments.


================
Comment at: test/sanitizer_common/TestCases/NetBSD/strtonum.cc:13
+
+  l = strtonum("100", 1, 100, &errstr);
+  if (errstr)
----------------
vitalybuka wrote:
> krytarowski wrote:
> > vitalybuka wrote:
> > > vitalybuka wrote:
> > > > what is going to happen with following?
> > > > strtonum("100 long suffix....", 0, 1000, &errstr)
> > > > if this stops parsing just after 100 then COMMON_INTERCEPTOR_READ_RANGE(ctx, nptr, REAL(strlen)(nptr) + 1)  is performance bottleneck
> > > > maybe we should get actual read size with StrtolFixAndCheck
> > > > 
> > > > we had issues with other strto* with strict_string_checks=1 on parsers like python
> > > > it just calls such methods in the middle of a large file and you get O(N) -> O(N^2)
> > > > 
> > > >> maybe we should get actual read size with StrtolFixAndCheck
> > > correction: get actual read size with different strto* call and pass it into StrtolFixAndCheck
> > `strtonum("100 long suffix....", 0, 1000, &errstr)` it will stop parsin after 100 on ' '.
> > 
> > src.illumos.org/source/xref/openbsd-src/lib/libc/stdlib/strtonum.c
> According implementation form src.illumos.org/source/xref/openbsd-src/lib/libc/stdlib/strtonum.c
> it uses strtoll
> So if we intercept strtoll, we just need to unpoison errstrp, it it was in existing implementation. What is the problem this patch is solving?
Do you mean what the interceptor code is solving? Reading input string only as much as the strtonum(3) function and unpoisioning errstr.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54527/new/

https://reviews.llvm.org/D54527





More information about the llvm-commits mailing list