World: r3wp

not tested though...

Only in R3, though, where, per default, shift == lshift, in R2 shift 
== rshift.

ah yes, I forgot

R2 needs shift/left to lshift, R3 rshifts with negative offsets.

And Brian, I fear your function is flawed.

>> in-ip-range? "10.10.10.10" "10.10.0.0/24" ; == true
Which is wrong.

From a quick glance your masking logic is wrong. You need to mask 
both the address and the network and then compare if the results 
match.

I guess it's in the last line::::
ip-as-integer = (ip-as-integer and mask-integer)

I have a correct function for R3 lying around somewhere ... if only 
I could find it :)

Ah, got it.

cidr-match?: funct [address [tuple!] network [tuple!] bits [integer!]] 
[
    mask: skip to-binary (shift -1 32 - bits) 4
    (mask and to-binary address) = (mask and to-binary network)
]

not R2 though ;-)

For R3
, as I mentioned.

I on

Usage:
>> cidr-match? 10.10.10.10 10.10.0.0 16 ; == true
>> cidr-match? 10.10.10.10 10.10.0.0 24 ; == false

It's much nicer in R3, as to-binary on numbers works properly :)

In any case, here's an R2 version (assuming 2.7.7+ for funct):


cidr-match?: funct [address [tuple!] network [tuple!] bits [integer!]] 
[
    mask: shift/left -1 32 - bits

    (mask and to-integer to-binary address) = (mask and to-integer to-binary 
    network)
]

See that weird one :)


cidr-match?: funct [address [tuple!] network [tuple!] bits [integer!]] 
[
    mask: to-tuple skip to-binary (shift -1 32 - bits) 4
    mask and address xor network = .0.
]

Andreas, I'm sure my function is flawed - I just came up with it 
right then. Thanks for the fix :)

rather optimized...


cidr-match?: funct [address [tuple!] network [tuple!] bits [integer!]] 
[
    mask: to-tuple to-binary shift -1 64 - bits
    mask and address xor network = .0.
]

Heh, that's great Steeve. Esp the ".0."

yeah,
.0. = 0.0.0 = 0.0.0.0.0 ...

Yeah :)

Yeah, silly me, forgot about SHIFT :)

That should work on R2 with 32 instead of 64.

Yup

Nope. You'd need shift/left on R2

He knew... :)

Just a reminder :)

The last time I did IP calculations in REBOL was before 2.7.6 came 
out, so the reminder is appreciated :)

Though your functions do indicate the value of using REBOL's datatypes 
properly. Take note, Pekr, no strings :)

wow, what a bunch of reactions :-) BrianH - I used strings, because 
of original Mikrotik format. They use 10.10.10.10/24 format for IP, 
so it was easier for me to carry around in a string form, then parse 
it later when needed ....


IP arithmetics, and ranges would be 2 nice new datatypes for REBOL 
imo :-)

Steeve - your optimised version for R2 does not work correctly:

>> cidr-match? 10.10.10.10 10.10.10.0 24
== false

Because it was for R3 only, try this for R2:


cidr-match?: func [address [tuple!] network [tuple!] bits [integer!]] 
[

    address xor network and (to-tuple debase/base to-hex shift/left -1 
    32 - bits 16) = .0.
]

Don't know if it's faster than Andreas's, though

(-:-:- = -:0:-) = (0:-:0 = 0:0:0)

-:-

and so:
+:+

I'm trying to figure out which index comes earlier in two different 
references to the same block and was trying with MIN and MAX, because 
I didn't want to resort to LESSER? INDEX? things.


The result with MIN/MAX doesn't seem to be particularly useful. What 
is the basis of comparison of two blocks when using MIN and MAX?

Their contents, not their indexes.

yes, I figure that, but what's the basis for comparison?

...

Their first elements, as in
>> max [0 9 9] [2]
== [2]

are you sure?

>> min [b 1] [b b 2]
== [b b 2]

also because MIN and MAX don't compare on words, so there must be 
a different base of comparison.

>> min reduce [word! integer!] reduce [word! word! integer!]
== [word! word! integer!]

MIN and MAX compare the spelling of words in blocks in R3.

And it's not just the first element:
>> min [b b] [b a]
== [b a]

Henrik just showed that.

If the types aren't the same the datatypes are compared, by the arbitrary 
ordering they have in the type list (the datatype number).

Henrik: it's the same as SORT