octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Stories from static analysis of the Octave code base


From: Rik
Subject: Stories from static analysis of the Octave code base
Date: Fri, 4 Jan 2019 11:35:24 -0800

All,

It's been a humbling experience going through the issues detected by static
analysis of the Octave code base
(https://wiki.octave.org/PVS_static_analyzer_-_5.0_Release).  Frankly, I
thought the code base was better than it turned out to be.  Besides flat
out calling the wrong function (e.g., double_value instead of
xdouble_value), I just found and corrected a surprisingly simple but
pervasive performance hit for any exceptional value (-Inf, Inf, NaN).

The code in question is deep in liboctave at liboctave/util/lo-ieee.cc. 
The representation of an IEEE exceptional value on the particular HW Octave
is running on is found and then stored away so that subsequent uses just
retrieve that value rather than re-deriving it each time.  The
initialization code was

void
octave_ieee_init (void)
{
  bool initialized = false;

  if (! initialized)
    {
       ... code to find and store exceptional values ...
       initialized = true;
    }
}

As you can see, initialized is always false so the longer code to derive
the exceptional values is run every single time.  And the exceptional
values themselves are functions which end up calling octave_ieee_init
twice: once for the "double" value and once for the "single" value.

Also, despite their name, Octave uses exceptional values quite a bit.  For
example, graphics handles are often initialized to NaN until they can be
assigned a true handle.

In this case, the solution was quite simple.  The declaration of
"initialized" just needed the static keyword to make this variable
persistent.  I wish all bugs were that simple to correct.

--Rik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]