"Artur Skawina via Digitalmars-d" wrote in message
news:mailman.227.1406728603.16021.digitalmar...@puremagic.com...
"D - the language that redefines commonly used and universally
understood terms and concepts"?
Yes, see pure for another example. "D - the pragmatic language"
> not that it can't work the way Walter and I have described.
Possible != sane.
The main problem isn't even the terminology; it's the consequences
wrt safety and correctness.
Yes, this is a much more useful discussion to have than what other people
have definined assert to do.
Consider a service/program that handles user supplied data. It
uses several third-party libs, one for parsing and validating the
inputs, another for some other processing/communication, etc.
One is carefully written with security in mind and can safely
deal with every possible valid or invalid input. Another was not
considered security sensitive and designed to work on valid data.
The input requirements are just documented and only checked via
asserts. Now the programmer implementing that service only needs
to make a single mistake, so that an invalid (or just unexpected)
input is passed to the less hardened lib. In a production setting
the asserts are not present, but the assumptions have leaked to
the other libs, and some of the carefully written checks have been
statically eliminated by the compiler. Code that was perfectly safe
gained an invisible (!) security hole, because of an innocent
looking assert statement in a different code base.
Yes, it is a very powerful and dangerous optimization capability. If the
optimization benefits are not worth the potential escalation of code
wrong-ness, then don't enable it. If security is more important than speed,
don't disable assertion and bounds checks.
If used wrong it will do the wrong thing. This is already true of compiler
optimizations. The optimizer may turn invalid code into security problems -
have a google around and you'll find some examples.
