Wireshark-bugs: [Wireshark-bugs] [Bug 9263] Buildbot crash output: fuzz-2013-10-10-12811.pcap
Comment # 18
on bug 9263
from Chris Maynard
(In reply to comment #17)
> While I'm not happy with the change in general I find the existing solution
> even worse.
I fail to see how things are worse, but maybe I'm in the minority here.
> What I am unhappy with the the text in tvbuff.h, as it implies
> that a return value of 0 indicates an access outside the valid range of the
> buffer.
Well, a return value of 0 does indicate an access outside the valid range of
the buffer, doesn't it? Even in the case when you have a buffer of N bytes in
length, an offset of N is outside the valid range of the buffer, is it not?
> Proposed text:
>
>
> /** Computes bytes to end of buffer, from offset (which can be negative,
> * to indicate bytes from end of buffer). Function returns 0 if offset is
> * either at the end of the buffer or out of bounds. No exception is thrown.
> */
I consider the end of the buffer to be out of bounds already, but if you think
this wording is clearer, or for that matter if you think the change in r52571
itself isn't acceptable, then I guess go ahead and make whatever changes you
think are best.
I am curious though - I'm aware of many of the types of problems that can be
caused by those functions returning -1, but I'm unaware of any problems caused
by the change in r52571. Is there some specific instance you can point to? Is
there somewhere in the code where a return value of 0 is treated differently
from -1 where there's any real impact? Basically what is it exactly that makes
this change worse than the previous behavior? I'm honestly curious so I can
learn from this, because if I've misunderstood the impact, then I'd like to
know about it and learn from it. Thanks.
You are receiving this mail because:
- You are watching all bug changes.
