Mailing List Archive

On Sun, 2003-01-12 at 15:52, Michel Arboi wrote:
> Now that NASL can accept complex expressions, do you have any
> preferences for the operator precedence?

The same rules than in C/C++ would be just great IMHO.

Cordialement,

--
Vincent RENARDIAS
Directeur Technique
StrongHoldNET / http://www.strongholdnet.com

Vincent Renardias <vincent@strongholdnet.com> writes:

> The same rules than in C/C++ would be just great IMHO.

Precedence for bit operations (& and |) sucks in C
The other operators are OK.

On Mon, 2003-01-13 at 11:54, Michel Arboi wrote:
> Vincent Renardias <vincent@strongholdnet.com> writes:
>
> > The same rules than in C/C++ would be just great IMHO.
>
> Precedence for bit operations (& and |) sucks in C

Indeed, but people have been used to that for a long time. Trying to
"repair" this in NASL will probably result in many bugs since I assume
many NASL plugin writers are very much used to C.

Wishlist Item: When there is an ambiguous use of precedence, NASL might
issue a warning about it (exactly like gcc does) ?

Cordialement,

--
Vincent RENARDIAS
Directeur Technique
StrongHoldNET / http://www.strongholdnet.com

Vincent Renardias <vincent@strongholdnet.com> writes:

> Indeed, but people have been used to that for a long time.

I've been coding in C for 15+ years and I cannot get used to this
stupid precedence. It forces everybody to use parenthesis, even when
they are not necessary, because it is so unintuitive.

> Trying to "repair" this in NASL will probably result in many bugs
> since I assume many NASL plugin writers are very much used to C.

Well, NASL is rather different from C, so...

> Wishlist Item: When there is an ambiguous use of precedence, NASL might
> issue a warning about it (exactly like gcc does) ?

Mmmm... Too complex I am afraid.

On 13 Jan 2003, Michel Arboi wrote:

> > Wishlist Item: When there is an ambiguous use of precedence, NASL might
> > issue a warning about it (exactly like gcc does) ?
>
> Mmmm... Too complex I am afraid.

I am not sure whether gcc does it this way but I think you can add an
"explicit parentheses flag" (EPF) to every operator node in the parse tree
and check for an existence of two operator nodes such that one is the
parent of another, the pair of operators they represent has confusing/
ambiguous precedence and the child node has its EPF unset.

Somewhat tedious but feasible.

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