[Scilab-Dev] legacy 5.x syntax deserves to be abandonned

Stéphane Mottelet stephane.mottelet at utc.fr
Fri Jul 20 20:30:46 CEST 2018



> Le 20 juil. 2018 à 20:24, Samuel Gougeon <sgougeon at free.fr> a écrit :
> 
>> Le 22/06/2018 à 10:28, Stéphane Mottelet a écrit :
>> 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.
> 
> 
> If you consider the very close syntaxes like
> myfun(a, , c)
> or
> myfun(, b, c)
> also as too permissive and to be forbidden, then we would definitely disagree:
> 
> To me, they are to most handy way to skip an argument (obviously provided that myfun() handles it correctly).

The problem is that the number of functions that actually *do not* handle it is unknown/unbounded....

S.

> 
> Does your proposed patch also prevent them?
> 
> Samuel
> 
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev




More information about the dev mailing list