> Le 20 juil. 2018 à 20:24, Samuel Gougeon <sgoug...@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@lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev
