Mailing List Archive: NASL2 arrays & integer index

NASL2 arrays & integer index

Jan 11, 2003, 3:43 AM

Post #1 of 5 (1073 views)

I have a problem with the arrays: currently, character and numerical
indexes are implemented as hashes.
This means that NASL will be efficient on code like this:
v[-17] = "something";
v[66666] = "AAA";
v["A"] = "B";

Unfortunately, this break the index order in numerical arrays.
Implementing push() or max_index() is a pain in the back, and
make_list() is broken with array arguments.
e.g.
for (i = 1; i < 20; i++) v[i] = i;
w = make_list('zero', v, 'infinite');
for (i = 1; w[i]; i ++) display(w[i], '\n');

This works fine as long as n is small (< 7), but if you change the
loop to go to 20, the list is shuffled.

As we cannot have "the butter and the money of the butter", I suggest
that we use C arrays for the numerical indexes.
This means that the base index will be 0 (maybe I'll implement
something like $[. in Perl), that negative indexes will not be
supported (at least in the first version), and that access to big
indexes will waste much memory.

On the other hand, it will be easy to keep to implement things like
pop and push, max_index, the magical PHP empty index (v[]=next_value;)
etc.

There is also another vicious problem with those hashed arrays: they
are used to transfer parameters to functions.
Currently, this does not work:
x=NULL; # undefined the variable
display('One ', x, ' Two');
You'll never see two because display stops at the first undefined
variable. This is rather a design flaw in the interface and
a bug in nasl_display, anyway, it would be simpler with C 0-based
arrays.

BTW, should I start writing a NASL2 reference manual?

--
mailto:arboi@bigfoot.com
GPG Public keys: http://michel.arboi.free.fr/pubkey.txt
http://michel.arboi.free.fr/ http://arboi.da.ru/
FAQNOPI de fr.comp.securite : http://faqnopi.da.ru/

Re: NASL2 arrays & integer index [ In reply to ]

peak at argo

Jan 12, 2003, 8:17 AM

Post #2 of 5 (1052 views)

Permalink

On 11 Jan 2003, Michel Arboi wrote:

> Unfortunately, this break the index order in numerical arrays.
> Implementing push() or max_index() is a pain in the back, and
> make_list() is broken with array arguments.

max_index() is easy as long as no entries are deleted--just remember
the maximal occupied numeric index. push() is easy when you have
max_index().

> As we cannot have "the butter and the money of the butter", I suggest
> that we use C arrays for the numerical indexes.

Do you suggest that NASL arrays would have a "hash component" for string
indices and an "array component" for numerical indices?

What would be the result of the following piece of code?

v["x"] = 1;
v[0] = 2;
w = make_list("xyz", v, "abc")

[ 0:"xyz", 1:0, 2:"abc" ]? Or [ 0:"xyz", 1:0, 2:"abc", "x":1 ]?
Anything else?

Would array[max_index] = NULL shrink the array or just replace its
last entry with an undefined value?

> BTW, should I start writing a NASL2 reference manual?

Sure. :)

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

Re: NASL2 arrays & integer index [ In reply to ]

arboi at noos

Jan 12, 2003, 9:08 AM

Post #3 of 5 (1051 views)

Permalink

"Pavel Kankovsky" <peak@argo.troja.mff.cuni.cz> writes:

> max_index() is easy as long as no entries are deleted

OK, but how do we keep order?

> Do you suggest that NASL arrays would have a "hash component" for string
> indices and an "array component" for numerical indices?

Yes.

> What would be the result of the following piece of code?

Well, we have to decide if hash components are after or before the
array components. I think that after is better.
So...

> v["x"] = 1;
> v[0] = 2;
> w = make_list("xyz", v, "abc")

w = [0: "xyz", 1: 2, 2: 1, 3: "abc"]

> Or [ 0:"xyz", 1:0, 2:"abc", "x":1 ]?

Or maybe we keep then as hash components. So...
w = [0: "xyz", 1: 2, 2: "abc", "x": 1]

Yes, this looks better.
But we have to chose what wmake_list() will do with duplicated
index. I suggest that the last value takes precedence, the code will
be simpler.

> Would array[max_index] = NULL shrink the array or just replace its
> last entry with an undefined value?

Internaly, it will be a VAR2_UNDEF but max_index should be updated.

Re: NASL2 arrays & integer index [ In reply to ]

peak at argo

Jan 13, 2003, 10:10 AM

Post #4 of 5 (1055 views)

Permalink

On 12 Jan 2003, Michel Arboi wrote:

> > max_index() is easy as long as no entries are deleted
> OK, but how do we keep order?

We do not have to keep order. Everything you need to know is that
0..max_index are valid indices and you have got a method (the hash)
to access values assigned to these indices.

> Well, we have to decide if hash components are after or before the
> array components. I think that after is better.
> So... [...]
> w = [0: "xyz", 1: 2, 2: 1, 3: "abc"]

Silent "arrayisation" (doh, it sounds like "aryanisation") is a kind of
suprise I myself would not like. Otoh, an explicit function returning
the values ordered by their keys (i.e. something like ``map { $hash{$_} }
(sort { ... } keys %hash)'' in Perl) might be quite useful (I do not say
you have to implement it now).

> Or maybe we keep then as hash components. So...
> w = [0: "xyz", 1: 2, 2: "abc", "x": 1]
>
> Yes, this looks better.
> But we have to chose what wmake_list() will do with duplicated
> index. I suggest that the last value takes precedence, the code will
> be simpler.

On second thought, perhaps entries having "non-array" indices (i.e.
strings or negative numbers (?)) should always make make_list() fail. At
least when they occur in multiple arguments / arguments are than the first
one. We can always let the genie out of the bottle when someone finds a
(reasonable) use for it...

> > Would array[max_index] = NULL shrink the array or just replace its
> > last entry with an undefined value?
>
> Internaly, it will be a VAR2_UNDEF but max_index should be updated.

It makes sense but it can be quite tricky, e.g.

array[max_index-1] = NULL;
array[max_index] = NULL;

The other command should detect the previous entry is undefined as well
and shrink the array by *two* entries.

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

Re: NASL2 arrays & integer index [ In reply to ]

arboi at noos

Jan 14, 2003, 11:10 AM

Post #5 of 5 (1055 views)

Permalink

Pavel Kankovsky <peak@argo.troja.mff.cuni.cz> writes:

> We do not have to keep order.

Not for max_index, but for other operations, yes we do. Otherwise,
there will be no other way to access the values in the order of the
numeric key than write a "for" loop.

> On second thought, perhaps entries having "non-array" indices (i.e.
> strings or negative numbers (?)) should always make make_list()
> fail. At least when they occur in multiple arguments / arguments are
> than the first one.

A big and dirty warning?

> It makes sense but it can be quite tricky, e.g.
> array[max_index-1] = NULL;
> array[max_index] = NULL;
> The other command should detect the previous entry is undefined as well
> and shrink the array by *two* entries.

Just need a "while" instead of a plain "if"