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.
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)