{"action":"created","issue":{"url":"https://api.github.com/repos/supercollider/supercollider/issues/1993","repository_url":"https://api.github.com/repos/supercollider/supercollider","labels_url":"https://api.github.com/repos/supercollider/supercollider/issues/1993/labels{/name}","comments_url":"https://api.github.com/repos/supercollider/supercollider/issues/1993/comments","events_url":"https://api.github.com/repos/supercollider/supercollider/issues/1993/events","html_url":"https://github.com/supercollider/supercollider/issues/1993","id":150631110,"number":1993,"title":"OSC interface: Please support N (nil) type tag","user":{"login":"jamshark70","id":318301,"avatar_url":"https://avatars.githubusercontent.com/u/318301?v=3","gravatar_id":"","url":"https://api.github.com/users/jamshark70","html_url":"https://github.com/jamshark70","followers_url":"https://api.github.com/users/jamshark70/followers","following_url":"https://api.github.com/users/jamshark70/following{/other_user}","gists_url":"https://api.github.com/users/jamshark70/gists{/gist_id}","starred_url":"https://api.github.com/users/jamshark70/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jamshark70/subscriptions","organizations_url":"https://api.github.com/users/jamshark70/orgs","repos_url":"https://api.github.com/users/jamshark70/repos","events_url":"https://api.github.com/users/jamshark70/events{/privacy}","received_events_url":"https://api.github.com/users/jamshark70/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/supercollider/supercollider/labels/comp:%20lang","name":"comp: lang","color":"CFFF7D"},{"url":"https://api.github.com/repos/supercollider/supercollider/labels/comp:%20scsynth","name":"comp: scsynth","color":"F4FF75"},{"url":"https://api.github.com/repos/supercollider/supercollider/labels/enhancement","name":"enhancement","color":"84b6eb"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2016-04-24T05:59:15Z","updated_at":"2016-04-25T13:47:59Z","closed_at":null,"body":"Currently, `nil` in an OSC message array is converted to an integer 0 in the outgoing message. This makes it impossible for the receiver to know if it's a legitimate attempt to send 0, or a failure condition.\r\n\r\nThis is definitely occurring in sclang's OSC primitives:\r\n\r\n```\r\n[\"/b_free\", nil].asRawOSC\r\n-->\r\nInt8Array[ 47, 98, 95, 102, 114, 101, 101, 0, 44, 105, 0, 0, 0, 0, 0, 0 ]\r\n```\r\n\r\n... where 105 is the type tag for 'i' and the data bytes are 0. Further, if you send such a message (as below) to, say, PD, you'll cleanly get `[\"/b_free\", 0]` on the other side.\r\n\r\n```\r\nn = NetAddr(\"127.0.0.1\", 9997);\r\nn.sendMsg(\\b_free, nil);\r\n```\r\n\r\nNow... why am I picking on `/b_free`? Because here is a case where you absolutely do not want the server to take action on wrong information. But, if you free a Buffer object and, sometime later, free it again, Buffer will build exactly the message `[\"/b_free\", nil]` -- which will be sent to the server as `[\"/b_free\", 0]` whereupon any data that you have carefully stored in buffer 0 will be destroyed.\r\n\r\nI've put in a pull request to stop Buffer from building/sending a \"free\" message in this case, but this won't help other clients. I think the only comprehensive solution is to send the message to the server exactly as it was built, nil and all, and let the server fail the command and send the failure response back to the client.\r\n\r\nIn most cases, a 0 default doesn't do much damage. But in this case... I could fill the entire next screenful with expletives and still not manage to express exactly how thoroughly, appallingly unacceptable the current situation is.\r\n\r\nWe take too many shortcuts in interface design, and the users end up paying for it."},"comment":{"url":"https://api.github.com/repos/supercollider/supercollider/issues/comments/214336185","html_url":"https://github.com/supercollider/supercollider/issues/1993#issuecomment-214336185","issue_url":"https://api.github.com/repos/supercollider/supercollider/issues/1993","id":214336185,"user":{"login":"muellmusik","id":1315053,"avatar_url":"https://avatars.githubusercontent.com/u/1315053?v=3","gravatar_id":"","url":"https://api.github.com/users/muellmusik","html_url":"https://github.com/muellmusik","followers_url":"https://api.github.com/users/muellmusik/followers","following_url":"https://api.github.com/users/muellmusik/following{/other_user}","gists_url":"https://api.github.com/users/muellmusik/gists{/gist_id}","starred_url":"https://api.github.com/users/muellmusik/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/muellmusik/subscriptions","organizations_url":"https://api.github.com/users/muellmusik/orgs","repos_url":"https://api.github.com/users/muellmusik/repos","events_url":"https://api.github.com/users/muellmusik/events{/privacy}","received_events_url":"https://api.github.com/users/muellmusik/received_events","type":"User","site_admin":false},"created_at":"2016-04-25T13:47:59Z","updated_at":"2016-04-25T13:47:59Z","body":"> In that case, BufFreeCmd could simply pass a default that will not accidentally destroy user data, couldn't it? And this would not affect defaults for other commands where a 0 default would not be damaging?\r\n\r\nNo, I think it's more complex than that. Essentially you need to know what happened, i.e. did the user pass no arg? explicit nil? a wrong type (for this message)? Maybe, was there a cast from something to the expected type? You might handle these differently. Just passing a default that 'doesn't destroy' user data might actually be worse than the current situation, as it could make it harder to discover.\r\n\r\nI think if this is going to be done it should be done right, not just a fix for some particular class of use cases."}}