Slashdot Mirror
Typing These 8 Characters Will Crash Almost Any App On Your Mountain Lion Mac
An anonymous reader writes "All software has bugs, but this one is a particularly odd one. If you type "File:///" (no quotes) into almost any app on your Mac, it will crash. The discovery was made recently and a bug report was posted to Open Radar. First off, it’s worth noting that the bug only appears to be present in OS X Mountain Lion and is not reproducible in Lion or Snow Leopard. That’s not exactly good news given that this is the latest release of Apple’s operating system, which an increasing number of Mac users are switching to. ... A closer look shows the bug is inside Data Detectors, a feature that lets apps recognize dates, locations, and contact data, making it easy for you to save this information in your address book and calendar."
Not likely. It crashes due to an assertion failure and subsequent exception being thrown.
Landon Fuller has posted a gist on GitHub with an explanation of the bug and a binary patch to the affected library.
This sig is umop apisdn.
I have also had the impression that assert() is a hack that shouldn't be used much (?).
$ man assert
NAME
assert -- expression verification macro
SYNOPSIS
#include
assert(expression);
DESCRIPTION
The assert() macro tests the given expression and if it is false, the
calling process is terminated. A diagnostic message is written to stderr
and the abort(3) function is called, effectively terminating the program.
If expression is true, the assert() macro does nothing.
The assert() macro may be removed at compile time with the cc(1) option
-DNDEBUG.
Somebody forgot to remove some debugging code, embarrassing but hardly something that hasn't happened before and definitely not the end of the world as we know it.
Only to idiots, are orders laws.
-- Henning von Tresckow
as a programmer myself, when coding something and a harmless and not completely unexpected input occurs, your program shouldn't crash, due to any reason, asserts included. Such a failure is sign of nothing but lazy programming and even lazier unit testing.
Sorry, but you are wrong.
By the time you fail an assertion, you better crash because you're not supposed to be there. The code in FRONT of the assertion is supposed to prevent that.
Assertions go between the input checking front, and the sane input needing rear. Their only purpose in life is to prevent an unknown state in the rear guts, not to do what should have been done up front.
You don't understand what assert() is for.
It doesn't cause a crash. Quite the opposite. It is a way of deliberately causing program termination upon encountering an internal inconsistency; precisely so as to avoid a crash, a silent failure or some other undesirable behavior.
Obviously, in a bug-free program, assert() would never trigger and is therefore unnecessary. In the real world it is a useful safety net.
Note that assert() is sometimes used to catch runtime errors. That is indeed inappropriate. But you shouldn't condemn the tool because it is sometimes used incorrectly.
Then instead of an assert you should have a return error (or throw exception) statement.
No. Those can only ever be for foreseen error states. If they are not foreseen, then they are no documentable, and therefore the calling code can take no sensible action to react to the error or exception.
An assert is a documentation of something that's always true and will never fail. If it fails, that's a bug, and there's no graceful handling of bugs - if you could foresee them, you would have already fixed them.
The question is whether to only have them in debug builds or whether to have them in release builds too. Contrary to your ASSERTION, asserts aren't necessarily compiled out of release builds. The answer is they go in release builds too if the worst case scenario is data corruption from continuing in an unpredictable state.
None of this is in Programming 101. This is stuff you learn when you've been programming a long time.