On Oct 28, 2011, at 10:45 AM, Stig Bjørlykke wrote:
> The checks will introduce more conversions from string to integer, but
> that may not be an issue?
Unless somebody has a Wireshark extension or script running TShark or something
of that sort that attempts to compile millions of filters per
On Fri, Oct 28, 2011 at 7:06 PM, Stephen Fisher
wrote:
> On Fri, Oct 28, 2011 at 09:00:59AM +0200, Stig Bjørlykke wrote:
>> The previously attached patch does check for signed/unsigned issues,
>> and will mark the filter as bad/red. I think it would be nice to check
>> all values if they are valid
On Fri, Oct 28, 2011 at 09:00:59AM +0200, Stig Bjørlykke wrote:
> On Thu, Oct 27, 2011 at 9:12 PM, Stephen Fisher
> wrote:
> > Is there a problem with accepting -1 in that filter?
>
> It's not a problem, but it's a bug in the logic because the filter
> does not do what it's supposed to.
I under
On Thu, Oct 27, 2011 at 9:12 PM, Stephen Fisher
wrote:
> Is there a problem with accepting -1 in that filter?
It's not a problem, but it's a bug in the logic because the filter
does not do what it's supposed to.
> If so, should the
> filter be checked against possible values of the value, i.e. t
On Thu, Oct 27, 2011 at 08:28:43AM +0200, Stig Bjørlykke wrote:
> On a 32-bit system the display filter "tcp.len < -1" seems to be
> valid, and does return all TCP packets.
> The attached patch fixes this, but can we do this check in a simpler
> manner?
Is there a problem with accepting -1 in
Hi.
On a 32-bit system the display filter "tcp.len < -1" seems to be
valid, and does return all TCP packets.
This happens because we use strtoul() to convert the string "-1" to a
unsigned long, and the documentation states that "the string is
converted to an unsigned long value in the obvious man
