search

berkus / snappy

Automatically exported from code.google.com/p/snappy
0 stars 0 forks source link

Bug in IncrementalCopyFastPath #84

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
There is a check for len > 0 in IncrementalCopyFastPath.

However, len is of type size_t, and when it goes negative, it is possible for 
the if check to fail.

casting len to an (int) during the check resolves the problem.

Original issue reported on code.google.com by justin.h...@gmail.com on 14 Jan 2014 at 7:29

GoogleCodeExporter commented 9 years ago 
When I say "if check to fail"', I don't mean fail as in a good fail... I mean 
it fails to recognize that len is not > 0, and it causes the code to execute, 
while it should in fact abort.

Original comment by justin.h...@gmail.com on 14 Jan 2014 at 7:30

GoogleCodeExporter commented 9 years ago 
Can you explain to me how len can go negative? size_t is an unsigned type.

Original comment by se...@google.com on 14 Jan 2014 at 7:43

GoogleCodeExporter commented 9 years ago 
Maybe that's the problem... it goes 'negative', so it actually wraps and causes 
problems.

The previous while loop that decrements len based on src/op doesn't do any 
sanity check to see if you are decrementing past zero, and thus wrapping.

Original comment by justin.h...@gmail.com on 14 Jan 2014 at 7:58

GoogleCodeExporter commented 9 years ago 
I think you're just misreading the function. len is not of type size_t, it is 
of ssize_t.

Original comment by se...@google.com on 14 Jan 2014 at 8:11

GoogleCodeExporter commented 9 years ago 
Ah, damn - mine is size_t -- not ssize_t.  Copy/Replace issue.

Ignore this.

Thanks!

Original comment by justin.h...@gmail.com on 14 Jan 2014 at 8:15

GoogleCodeExporter commented 9 years ago

Original comment by se...@google.com on 14 Jan 2014 at 8:22