Mailing List Archive

[NASL2] Metaphysical question on null values
NASL2 knows about uninitialized variables and have a NULL constant.

The code about addition, substraction and array indexing was rather
logical : adding or substracting anything to / from an undefined value
is undefined, and accessing an array element with an undefined index
is undefined too.
However, all this is silent and can be badly surprising.
So... Either we shout every time we try such an operation, or we
consider those undefined values as 0, at least for + - and [ ]
I was ready to vote for the 2nd option and started modifying the code,
but is this _really_ wise?
Re: [NASL2] Metaphysical question on null values [ In reply to ]
Michel Arboi wrote:
> NASL2 knows about uninitialized variables and have a NULL constant.
>
> The code about addition, substraction and array indexing was rather
> logical : adding or substracting anything to / from an undefined value
> is undefined, and accessing an array element with an undefined index
> is undefined too.
> However, all this is silent and can be badly surprising.
> So... Either we shout every time we try such an operation, or we
> consider those undefined values as 0, at least for + - and [ ]
> I was ready to vote for the 2nd option and started modifying the code,
> but is this _really_ wise?
>

Trade off _wise_ with ease of use. I think it is reasonable
for ease of use to consider NULL another 'type' that is cast
appropriately when used to do operations such as string
concatenation and numerical operations.

If uncomfortable, consider making it a configurable option
(ala PHP) and then set it to the one you want for the
main Nessus project.

Thomas
Re: [NASL2] Metaphysical question on null values [ In reply to ]
On 8 Feb 2003, Michel Arboi wrote:

> The code about addition, substraction and array indexing was rather
> logical : adding or substracting anything to / from an undefined value
> is undefined, and accessing an array element with an undefined index
> is undefined too.
> However, all this is silent and can be badly surprising.
> So... Either we shout every time we try such an operation, or we
> consider those undefined values as 0, at least for + - and [ ]

IMHO, any use of an undefined value (unless explicitly allowed) is a
very good reason (at least) to print a warning--no sane program should
ever do such a thing. The only problem with this might be the amount of
superfluous warnings should the interpreter generate one whenever an
undefined value is used. This problem might be addresses in three
different ways:

1. the program is terminated
2. the result of the operation having one or more undefined arguments is
a "secondary undefined value" and the interpreter does not generate
any warnings unless it encounters a "primary" (e.g. non-secondary)
undefined value
3. the undefined value is interpreted as 0 or "" (i.e. a neutral element
for the operation in question) and the operation returns a normal
result

Option 1 is likely to break to some scripts. Option 2 cannot be used for
conditional statements (if, while...). Option 3 might be tricky when an
overloaded operation is involved (is undefined + undefined == 0 or
""?)...or an operation having no natural neutral element (i.e. []!)--
the result should probably be undefined in these cases.

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."
Re: [NASL2] Metaphysical question on null values [ In reply to ]
"Pavel Kankovsky" <peak@argo.troja.mff.cuni.cz> writes:

> IMHO, any use of an undefined value (unless explicitly allowed) is a
> very good reason (at least) to print a warning--no sane program should
> ever do such a thing.

This happens with -DNASL_DEBUG=1
Unfortunately, function arguments are implemented as local variables,
and when a function tries to read an optional argument, you get a
warning.

> 1. the program is terminated

Easy to implement (once we fix the argument problem), but rather
dirty IMHO.