[Octave-bug-tracker] [bug #63437] Null pointer dereference in file-editor-tab.cc

[John W. Eaton]

Follow-up Comment #22, bug #63437 (project octave):

Back to the original issue reported here...

Do we want to try to avoid the static analyzer warning for something that is
not likely important?  There are *many* other places where the pointer to the
settings object is not checked before use.  I'd rather not add a bunch of
checks for that when the settings object is always supposed to be valid.  If
anything, we could add a check inside the resource_manager::get_settings
function that pops up a critical warning/error in a message box that says
something like "Something has gone horribly wrong and Octave has lost its
settings!  This is not supposed to happen!"
and then attempt to close the application.  Or we could have it try to throw
an exception and issue a message in the command window (that's what will
happen with error_unless/error_if).

For now, I checked in the following change:

http://hg.savannah.gnu.org/hgweb/octave/rev/132547cc1ab2

If the new error that it introduces happens, then we can try to figure out how
and why and work on a fix for a real problem.

Also, as discussed in the comments here, I intend to eliminate the pointer to
a single settings object by using local gui_settings (AKA QSettings) objects
that work the way Qt intended.  Then the local objects will always exist,
won't be pointers, and we won't have to check that they are not null.

The QSettings object manages thread-safe storage to the underlying global
settings data.  When the Qt docs say that operations on QSettings are not
thread safe, it means that you can't create a QSettings object in one thread
and use it in another without some locking.  But each QSettings object does
perform locking when reading or writing the underlying global data.  So
creating two distinct QSettings objects in different threads and calling value
or setValue is OK.  So I think it just makes a lot more sense to use local
QSettings objects instead of a single global one that then requires additional
care to avoid possible threading issues.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63437>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/