The following (fixed) bug
http://bugzilla.scilab.org/10279
shows that such a syntax was considered as an error, but only for
user-defined functions. (it has not been fixed at the parser level). I
don't see any reason why the syntax should be accepted for built-in
functions.
S.
Quoting Stéphane Mottelet <[email protected]>:
Hello,
While fixing
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=15623
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=15624
I discovered that gross syntax errors such as
max(,), max(1,) mean(,)...
are not trapped by the parser. As a consequence, tokens of type
internalType:ScilabVoid are given to the gateway in the input
arguments.
There are a lot of scilab functions which do not correctly handle
this. For example,
max(1,) and atan(1,) crash Scilab
max(,), gives a message about a missing overloading function for
ScilabVoid type.
Why such an dumb syntax has been kept as valid in Scilab 6 ? Does
even somebody remember if there exist some legacy code needing this ?
There is a potentially huge number of gateways to be fixed because
of this too permissive syntax.
However, all problems can be fixed by yanking lines 661:666 in
parseScilab.yy (666: Number of the Beast).
S.
--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.utc.fr/~mottelet
_______________________________________________
dev mailing list
[email protected]https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/dev
