Slashdot Mirror
Crash Chrome With 16 Characters
An anonymous reader writes: Remember when it took just eight characters to crash Skype? Apparently it takes double that to take out Chrome: Typing in a 16-character link and hitting enter, clicking on a 16-character link, or even just putting your cursor over a 16-character link, will crash Google's browser. To try it yourself, fire up Chrome 45 (the latest stable version) or older and put this into your address bar: http: //a/%%30%30 (without the space).
You mean "It's 2015 and developers still introduce bugs"... and frankly... no fucking shit. Yes, coding is hard. Every time you change code (and I'm sure the URL bar parsing code changes pretty regularly) you stand a chance of introducing a bug.
And this is one reason it is so insensible when highly skilled software developers get worried over this idea that everyone is going to get some programming background.
As soon as it hits the fan--and it will--they'll need someone to fix it. And in many cases it will happen over and over and over again, and push costs higher than just hiring someone to do it right to begin with.
I'm not worried.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
They probably do have some regression tests, but who would have written a unit test for an address with 16 characters in it? Some bugs are just so weird that no one even thinks to test for them.
True. Tests will tell you if something doesn't work, not if it does work. Automated tests are overrated anyways, they are more like a spell-check than a writing aid. I'd rather have a roomful of nonchalant, untrained users and unleash them on my product than trust the outcome of a series of tests written by biased developers.
I think you've fundamentally misunderstood the purpose and function of tests. If I realized this code would break in some corner case, I would have handled it. No developer would write code that fails his own tests. Granted, sometimes the process of writing tests aids your understanding but in that case you'd improve the code. That is true even for test-driven design, if you don't fully understand all the conditions that need testing, the test will be flawed or incomplete and the code too. The primary function is to prevent existing, working test cases from breaking by accident. Because let's face it, we're imperfect beings working on imperfect code and I've managed to break my own code plenty of times without realizing it, not to speak of someone else's work. Or we're mashing up modules in a new way using them in ways they were never meant to work, testing is also about verifying assumptions. Also by "work" I mean defined behavior, like if you divide by zero it's not supposed to work but it's supposed to fail in a controlled way. Testing is supposed to preserve behavior when the implementation changes. If it was never planned and tested behavior in the first place, well you're going to find out it changed the hard way.
Live today, because you never know what tomorrow brings