[PATCH] More string interceptors: strstr, strcasestr, strcspn, strpbrk
tetra2005 at gmail.com
Tue Apr 21 10:52:13 PDT 2015
Comment at: lib/sanitizer_common/sanitizer_common_interceptors.inc:322
@@ +321,3 @@
+ COMMON_INTERCEPTOR_READ_STRING(ctx, s2,
+ s1 && *s1 ? internal_strchr(s2, s1[r]) - s2 + 1 : 0);
+ COMMON_INTERCEPTOR_READ_STRING(ctx, s1, r + 1);
> dvyukov wrote:
> > m.guseva wrote:
> > > dvyukov wrote:
> > > > I don't believe this is necessary. Make it just:
> > > > READ_RANGE(s2, REAL(strlen)(s2) + 1);
> > > Why not?
> > > Indeed we don't need to read the full length of s2. User may expect it in non-strict case.
> > Because these are very complex expressions with lots of corner cases and potential off-by-ones.
> > User should not expect that the function won't read the whole string. There are not such guarantees in the documentation. Documentation refers to arguments as to strings. Strings are addressable zero-terminated regions of memory.
> >User should not expect that the function won't read the whole string. There are not such guarantees in the documentation.
> The "strict_string_checks" flag was introduced exactly cause user may expect such behaviour despite of documentation. Which are corner cases here? Can I just cover them?
I guess Dmitry means that there is a tradeoff between functionality and code complexity. And he'd prefer to drop overly complex checks in favor of simplicity.
More information about the llvm-commits