Posts by odyssey 13 publicly visible posts • joined 4 Mar 2020
Does anyone else feel like Rust is a sledgehammer to crack a nut? There is the nut of memory safety to crack but C is used partly because it's minimalist poetry. Rust puts tons of junk everywhere.
Why do you need let and fn to declare variables and functions? C gets by fine with int x.
I've thought for a while we need some lightweight extensions to C to allocate and free memory for common cases safely. But the language makes coding easy and that's why it because standard.
Garbage Collection should be the next to go. Developers have got lazy and dumb relying on someone else to manage their memory. So much efficiency could be gained looking at more efficient memory management. Rust, Zig, C, or something else - Deepseek and now this has shown that there are real software efficiency improvements to be made but only perhaps 10% of developers understand things well enough to make them.
But it seems to keep happening. It happens dozens of times a year including in code maintained by very experienced developers. The sudo maintainers are not n00bs. At some point we need to acknowledge that the C language makes this kind of error too easy to make, and that for all userspace programs some safer alternative is a priority.
Some commenters think automatic bounds checking solves the problem fully. It doesn't. If you get length calculations wrong in Java, you get a StringIndexOutOfBoundsException, an ArrayIndexOutOfBoundsException, etc. Same for other managed languages.
It doesn't solve the underlying problem, just mitigates it to a handled crash rather than a vulnerability. That's a lot better though, and most userspace programs should move off C for higher level languages with better string handling. But if you get the code wrong, you always get an issue - it's just that in a safe language it's an exception that's not exploitable.
The difficulty for the justices who I assume are not programmers is that programming is partly logic, partly art. Copyright is simple when it comes to art - Harry Potter is a creative work, if I wrote a book and had a school called Hogwarts I would be obviously copying it as I could have called the school anything else.
But when it comes to programming, there are many ways to express something (which is why programmers argue endlessly over languages and styles) but only so many ways to implement something. So if someone has a function called rangeCheck I could call my function examineTheRange just to be different, but I'm doing the same thing. I need to check if one number is greater than another, etc. I can call my variables what I like but I can't change what the function does. Logic means you can't make up what you like, art means you can - and software is a bit of both. This is going to be hard to understand for the justices because Oracle are going to use analogies with literature. But literature isn't a good analogy because you can always do whatever you like in your own novel. In programming you can't. And classes of functions are going to be limited - a File API would have open, close, read, write, etc - even if called something else to get around a copyright troll.
What's needed is an update of international copyright agreements, a Berne Convention 2, that fully recognizes that software is different from literature. And protects APIs from being copyrighted by recognizing them as logical expressions rather than creative works.
This reminds me of Bjarne Stroustrup's observation that there are two kinds of programming languages - the ones people complain about and the ones nobody uses. Excel is a good general-purpose tool for what it's meant for. There are lots of horror stories because it's so widely used. Any other tool that was as popular would have people misusing it. Most of the horror stories listed are human error.
Having said that, Excel is not meant to be used as a database (why MS makes Access and SQL Server). It's not MS or Excel's fault this happened, it's people stupidly importing csv files into a spreadsheet program when databases are the right tool for the job and freely available.
No I don't deny that. Higher-level languages make exploitable buffer overflows impossible, for example. They should be used for front-facing systems where possible, and usually are. This bug however isn't due to low-level C memory handling, neither are many other bugs. Therefore it's more rigorous testing that's needed.
"goto fail" specifically couldn't have happened in languages where "goto" isn't a thing. But you can create logic errors in every language. As we've seen with this Let's Encrypt bug, you can construct logically wrong code. You could write the equivalent of "goto fail" in a "goto-less" language, by getting a break or termination condition wrong.
For example the Zune player bug where a missing break clause in date calculation code caused an infinite loop. All languages could have such a bug, the language itself can never prevent it. That's why we need careful, rigorous testing. These bugs should really be seen as testing failures. A failure to verify that the code is correct in every possible condition.
I wouldn't say deserialization is a language quirk or gotcha. It can be used unsafely, but so can anything that lets untrusted users do things. Go's use of loop variables, the difference between = and ==, etc are gotchas because they look like they should do something different to what they actually do.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
