WhatsApp BO critical security vulnerability

[H. S. Teoh]

On Thu, May 16, 2019 at 04:58:25PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
> On Thursday, 16 May 2019 at 16:41:29 UTC, H. S. Teoh wrote:
> > What we need is a language with the right incentives: bounds
> > checking is default and it takes effort to turn it off (should that
> > ever become necessary), and the standard library should always have
> > an API that take bounds.
> 
> We have that language, it is called D.

I know. ;-)

When arrays come with bounds by default, the API doesn't have to be
uglified, and non-library code also benefits from default bounds
checking. Win-win.


> The only problem is so many people say "use -release -boundscheck=off"
> to get an extra percentage point on artificial benchmarks without
> educating people as to what that REALLY means.

Yeah, good ole premature optimization.  I sympathize, because I used to
be like that.  But after so many times of the profiler pointing to a
bottleneck that was far, far away from where I imagined it would be, it
finally dawned on me that *most* code actually doesn't even matter when
it comes to performance. And the small bit of code that's the bottleneck
usually is slowed down by something either completely non-obvious
(rare), or by something really silly (more common) like a misplaced
debug printf that eats up orders of magnitude more cycles than any
bounds check ever will.

Not to mention, with a proper optimizing compiler like ldc2 -O3, many
inner-loop bounds checks (where it matters) would be optimized away
anyway. And if it doesn't, it's usually just a small effort to rewrite
the code so that it doesn't need a bounds check.

Slapping -release -boundscheck=off across the board is just ...
hamfisted, and usually misguided.


T

-- 
There are two ways to write error-free programs; only the third one works.