System/Interpreter/Bugs/DesignReqd
Requests: Interpreter Bugs: Interpreter
Please restrict the headings to just two levels, with the actual bug reports placed at the top level; sign your submission using ~~~~; register the entry in the comment field below.
These reports/requests require new features, but the Dictionary is insufficient to define correct behavior. Design work is needed.
+"0 incorrectly gives error when applied to cell of fills
$ (i. 0 3) +"1 i. 0 2 |length error | $(i.0 3) +"1 i.0 2 $ (i. 0 3) +"+"1 i. 0 2 0
Apparently the test for length error is built into the + verb. But it doesn't follow the rules: + should be applied to a cell of fills, fail, and then use scalar numeric as the shape/type of the failed result. +"+ shows the correct behavior. -- Henry Rich <<DateTime(2012-12-23T22:21:30-0500)>>
Status: this may not be an error. A better definition of fill-cell processing is needed.
'' { empty y gives wrong shape
$ '' { i. 0 3
0 3
$ '' {"{ i. 0 3
0
0 is correct (fill-cell should be used, producing result of 0 $ ,: 0 { i. 0 3; but 0 { i. 0 3 fails, so 0 should be used; result shape 0). But { seems to treat '' the same as a: which would properly produce shape 0 3.
-- Henry Rich <<DateTime(2014-06-10T13:36:02Z)>>
Status: this may not be an error. A better definition of fill-cell processing is needed.
security level out of date
The foreign 9!:25, security level, is out of date. The Dictionary page for 9!: says (4495 586 qdoj 'dx009') :
9!:25 y
Security Level. The security level is either 0 or 1. It is initially 0, and may be set to 1 (and can not be reset to 0). When the security level is 1, executing Window driver commands and certain foreigns (!:) that can alter the external state cause a “security violation” error to be signalled. The following foreigns are prohibited: dyads 0!:n , 1!:n except 1!:40 , 1!:41, and 1!:42 , 2!:n , and 16!:n .
The errors are:
- There are no dyads 0!:n, and the monads 0!:n are not prohibited. (One can load a file from the filesystem using 0!:0<fn; though, nicely, one cannot display the contents of a file with 0!:011<fn.)
- The are 1!:n foreigns which are not dyads but are prohibited; notably, 1!:1.
- Moreover, the foreigns 1!:40, 1!:41, 1!:42 and (family) 16!:, don't exist. OTOH the foreigns 1!:43, 1!:44, 1!:45, and family 15!: do exist, and are not prohibited by security level (except for the 15!: family, which is).
- The wd commands are not prohibited (that is, the J engine still sends 11!:0 requests to the front end). Try 11!:0'qwd'[9!:25[1 in j.exe . Worse, try 11!:0 'wd winexec * DEL /F /Q some_important_file.
Analogous wording for current version of J:
9!:25 y
Security Level. The security level is either 0 or 1. It is initially 0, and may be set to 1 (and can not be reset to 0). When the security level is 1, executing Window driver commands and certain foreigns (!:) that can alter the external state cause a “security violation” error to be signalled. The following foreigns are prohibited: 0!:n with __display as in __ 0!:__01__n , __the foreigns__ 1!:n except 1!:4__3__ , 1!:4__4__, and 1!:4__5__ , 2!:n , and 1__5__!:n .
But even this language leaves something to be desired. J programmers may have more security concerns than it covers.
At the simplest, you might also consider prohibiting 0!:n entirely, and the entire 1!: family, including 43+i.3. The former allows one to read files from the host, and the latter provides potentially sensitive information about its structure. (Besides, why should a restricted user be allowed to change the working directory)?
For a more comprehensive solution, please see my custom security level request.
Applies to ( 'j601/2006-11-17/17:05';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)
Status: open
-- Dan Bron <<DateTime(2007-04-17T22:33:05Z)>>
Incorrect shape in u/. applied to empty
$ ]/. i. 2 4 5 2 $ ]/. i. 1 4 4 1 $ ]/. i. 0 4 0 0
The last shape should be 3 0.
-- Henry Rich <<DateTime(2014-11-18T02:23:02Z)>>
Status: open. The definition of what oblique means on an empty array has not been adumbrated. There is some appeal to making the shape 3 0 here, but since the structure of the result is lost, 0 0, which emphasizes that fact, has a claim.