On 06/14/13 09:35, Richard Sharpe wrote:
> On Fri, Jun 14, 2013 at 6:27 AM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> wrote:
>> On 06/13/13 20:46, Guy Harris wrote:
>>>
>>>
>>> On Jun 13, 2013, at 5:16 PM, Richard Sharpe <realrichardsharpe@xxxxxxxxx>
>>> wrote:
>>>
>>>> I thought I would try to work around my issue with smb.time vs
>>>> smb2.time by using a custom column field and putting in an expression,
>>>> but it seems not to work. An expression that is acceptable in the
>>>> Filter field is not acceptable in a custom column.
>>>>
>>>> Why is this?
>>>
>>>
>>> Because "||" is a Boolean "or", not a human-language "or". :-)
>>>
>>> I.e., "a || b" is a packet-matching expression that matches if the
>>> expression "a" matches or the expression "b" matches, not a field expression
>>> that evaluates to whichever of the fields "a" or "b" is present (with "a"
>>> chosen if both are present, presumably).
>>>
>>> The Filter field takes packet-matching expressions; the custom column
>>> field takes field names. Field names are valid packet-matching expressions,
>>> which match if the field is present in the packet and don't match if it's
>>> not, but arbitrary packet-matching expressions aren't valid as custom
>>> columns.
>>>
>>> Having a separate feature allowing a set of field names for a custom
>>> column could be useful. I'm not sure an "||" operator, given its existing
>>> meaning in C (and in packet-matching expressions), would be the right syntax
>>> for that.
>>
>>
>> What would an "or" in the context of columns mean? In particular in the
>> case where both fields have a value.
>
> Ahhh, the value of discussion.
>
> Since each is prefaced by a protocol name, in this case it would never
> happen. Perhaps it should use short circuit evaluation. The first that
> exists is the value that is used.
I suppose. But I live in a world where PDUs are very regularly bundled
together (often by SCTP's aggressive bundling but these days also by TCP
because the traffic rate is high enough). (And the connections in
question may be carrying different protocols once you get far enough up
the stack.)
The problem I see with a short-circuit is that you get one answer when
there are, in fact, two. We get beat up a fair amount over behaviors
when PDUs are bundled, we should be careful to avoid adding more.
What about separators? For example:
smb.time;smb2.time
We could make it smart enough to not print the separator if only one
field is present (for the common case). Supporting a set of separators
(semicolon, comma, and space come to mind) might be useful for different
types of fields. That might get ugly if someone wanted to do multiple
fields with different separators though...
