I promised a breakthrough for our next release.<\/p>\n
We are proud to announce JS++ efficiently analyzes and prevents out-of-bounds errors. An out-of-bounds error occurs when you attempt to access a container element that doesn’t exist in the container. For example, if an array has only three elements, accessing the tenth element is a runtime error.<\/p>\n
In C, you risk buffer overflows. In C++, you risk buffer overflows and exceptions. In Java and C#, you get an exception at runtime. If exceptions are uncaught, the application terminates. If segmentation faults occur, the application terminates. In the case of buffer overflows, you open your application to a variety of exploits.<\/p>\n
As we will show, we can perform out-of-bounds analysis with only a \u00b11-2ms (milliseconds) overhead on complex projects. There is virtually no effect on compile times with our invention.<\/p>\n
Out-of-bounds errors have plagued computer science and programming for decades. Detecting these errors at compile time has ranged from slow to impossible, depending on the language design. With that said, let’s first explore the problems which influenced the design.<\/p>\n
Basic Cases to Handle<\/strong><\/p>\n In all of the following cases, you cannot predict the value at compile time:<\/p>\n JS++ doesn’t stop at array indexes. Array indexes are limited to numeric values. What about arbitrary string keys on These are the basic cases. It gets more complex with branching logic:<\/p>\n These are the very basic cases. There are more… a lot more. All the corner cases you need to explore are outside the scope of this announcement.<\/p>\n Compile Times Must<\/u> Be Fast<\/strong><\/p>\n Efficiency is the key. We can’t announce 30% faster compile times in the previous release<\/a> and simultaneously promise a breakthrough that will cause compile times to explode exponentially.<\/p>\n Clearly, following every branch, virtual function call, external function call, and then some would not be a realistic proposal.<\/p>\n First, let’s look at a basic benchmark so we know what we’re comparing against. In the last release, 0.8.10, I measured “Hello World” compile times. With all of the analyses we added in 0.9.0 (the latest release), how much did it increase compile times for “Hello World”? A little under two (2) milliseconds:<\/p>\n\r\nimport System;\r\n\r\nint[] arr = [ 1, 2, 3 ];\r\n\r\nConsole.log(arr[Math.random(1, 100)]);\r\nConsole.log(arr[getUserInput()]);\r\nConsole.log(arr[getValueFromFile()]);\r\nConsole.log(arr[API.getTweetLimit()]);\r\n<\/pre>\n
System.Dictionary<T><\/code>? Yes, we handle these too:<\/p>\n\r\nimport System;\r\n\r\nauto dict = new Dictionary<string>();\r\n\r\nConsole.log(dict[Math.random(1, 100).toString()]);\r\nConsole.log(dict[getUserInput()]);\r\nConsole.log(dict[getTextFromFile()]);\r\nConsole.log(dict[API.getTwitterUsername()]);\r\n<\/pre>\n
\r\nimport System;\r\n\r\nDictionary<string> dict = {\r\n \"1\": \"a\",\r\n \"10\": \"b\"\r\n};\r\n\r\nbool yes() {\r\n return Math.random(0, 100) > 50;\r\n}\r\n\r\nif (yes()) {\r\n dict[\"20\"] = \"c\";\r\n}\r\n\r\nstring key = Math.random(0, 100).toString();\r\nif (dict.contains(key)) {\r\n Console.log(dict[key]);\r\n}\r\nelse {\r\n Console.log(dict[key + \"0\"]);\r\n}\r\n<\/pre>\n