On Tue, 19 Dec 2000 00:10:04 -0500 (EST)
Ed Warnicke <hagbard@xxxxxxxxxxxxxxxxxxx> wrote:
> Yes, I admit it. This is a religious point. Having been caught up
> in the elegance with which python thinks about sequences I tried to slip
> it's notion of slices in whole. I would say that the advantage of
> the [offset, finaloffset +1] notation is that it is in harmony with
> python, a language growing in popularity, and so retaining the
> [offset:length] notation would be confusing as python users thought they
> recognized a familiar convention and discovered they where wrong.
>
> Switching would break existing filters and confuse existing users.
I can't imagine that too many people depend on Ethereal's byte-slices, so
changing wouldn't be that bad.
> I propose the following compromise on the [i:j] case:
>
> 1) Ranges of the form [i:j] (j positve) will be considered to be
> [offset:length], as currently.
>
> 2) Ranges of the form [i:-j] will be considered to be
> [offset:maxoffset - j]. In otherwords [i:-j]
> denotes the range from the offset i to -j length from the end
> of the sequence.
>
> Examples:
>
> If for frame A bootp.hw.addr is 00:00:f6:00:00:01
>
> then
>
> bootp.hw.addr[2:2]
>
> would be f6:00 and
>
> bootp.hw.addr[2:-1]
>
> would be f6:00:00
Hmm, so the range f6:00:00:01 would either be bootp.hw.addr[2:4] or
bootp.hw.addr[2:-0] ? Is "-0" an allowable "j" argument? I guess I
think of the current [i:j] syntax as the parameters to the Perl splice()
function, where i is offset and j is length. A length of -1 includes
the last offset, so bootp.hw.addr[2:-1] would be f6:00:00:01.
You see that same influence in the way I implemented the tvbuff routines.
All the tvbuff functions that take an offset/length pair can accept
negative lengths, with -1 including that last offset like the
Perl splice() function.
BTW, I don't totally disagree with switch to a python-esque syntax. I'm
a big python fan.
> >
> > Most of the time, the RHS of a byte slice comparison will be countable
> > by the computer, so explicitly specifing a j argument wouldn't
> > be necessary (if we can come up with a good syntax for that).
>
> This true. The trick is coming up with a good consistent syntax for it.
I guess you'd want more of a function, rather than an equality comparison.
If we had a cmp() ("compare") function in our dfilter language:
cmp(bootp.hw.addr, 0, 00:00:f6)
That alleviates the binding problem, but may be worse from a user's point
of view.
>
> This still feels somewhat wrong to me. Not the part about the compiler
> doing the counting, but the general feeling that the [] operators
> SHOULD bind to the variable to their left. Its one of these nagging
> aesthetic certainties that defies all logic and reason.
Understood.
> It seems that we can agree on the following:
>
> 1) The [i] form should refer to single elements at offset i in
> the sequence.
>
> 2) variable[i:] should refer to the sequence from offset i
> in variable to the end of the sequence.
>
> I've put out a comprimise for consideration on the [i:j] form.
>
> We agree that having the compiler do the counting is a good thing, but
> that it requires a better syntax then what is in use currently.
> I stipulate that I want desparately to cling to my left binding of
> the [] operator but am willing to admit that this may be slightly
> childish.
>
> You have not commented on my points 7 and 8 which suggested
>
> 7) To have the variable name without a range operator
> refer to the whole variable.
>
> 8) Extend ranges to all sequence types.
Those sound fine. By defining some types as sequence types, we can
have an "in" operator like in python:
00:f6 in bootp.hw.addr
> If you could either accept, reject, or throw back for further discussion
> my [i:j] comprimise suggestion and my points 7 and 8 then I think we can
> formulate a plan to move forward.
7 and 8 are good. I'm not sure about the [i:j] compromise; I'm not totally
convinced that we should stay with [offset:length], but the length = -1
thing didn't seem right. And we still need a syntax for the []-binding
weirdness.
thanks,
--gilbert
