fix a few benign compiler warnings

• May 25, 2016 - 23:12
Reported version
3.0
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

gcc complains "-Wmisleading-indention" due to the manner in which this block of code form PR #2544 is indented:

                        if (e->isMarker())
                              if (toMarker(e)->markerType() == Marker::Type::FINE)
                                    continue; //added above^
                              rez = QString("%1 %2").arg(rez).arg(e->screenReaderInfo());

That first if statement is a single line if, which contains that second if statement, which contains the continue. But that final "rez = " is not part of that first if block. So it should have one less indentation. An alternative fix would be to combine the first two if statements into one:

if (e->isMarker() && toMarker(e)->markerType() == Marker::Type::FINE)

Comments

• May 25, 2016 - 23:14

But if the author intended that second if and the "rez =" to belong inside the same block of the first block of the first if statement, then should enclose them both in braces.

Reply

• May 25, 2016 - 23:19

I'm guessing from the title of the function, "BarLine::accessibleExtraInfo()", that this is probably not important, so doesn't seem to be be a bug. Anyway, I would say need to include both in braces since I would guess only want to add to the rez string if e is a marker. I'm making that conclusiong based on the earlier comment "//markers" above that block...

I'll submit a simple PR with added braces. I know not a biggie, but these warnings always annoy me.

Reply

• May 26, 2016 - 00:27

For the error:

/home/e/MuseScore/libmscore/bracket.cpp:74: warning: 'w' may be used uninitialized in this function [-Wmaybe-uninitialized]
       return w;
              ^

I'm fixing by adding having default case be the same as NO_BRACKET:

            case BracketType::NO_BRACKET:
            default:
                  w = 0.0;
                  break;

Reply

• May 26, 2016 - 00:43

similarly for:

/home/e/MuseScore/libmscore/layout.cpp:3057: warning: 'pbreak' may be used uninitialized in this function [-Wmaybe-uninitialized]
             bool pbreak;
                  ^~~~~~

I'm adding default case:

                  case LayoutMode::LINE:
                  default:
                        pbreak = false;
                        break;

Reply

• May 26, 2016 - 00:33

similarly for

/home/e/MuseScore/libmscore/systemdivider.cpp:60: warning: 'sid' may be used uninitialized in this function [-Wmaybe-uninitialized]
       if (!symIsValid(sid))
            ~~~~~~~~~~^~~~~

I'm doing:

            case SystemDivider::RIGHT:
            default:
                  sid = Sym::name2id(score()->styleSt(StyleIdx::dividerRightSym));
                  break;

Ideally, compiler should be smart enough to figure out that sid is always assigned to something, since _dividerType is an enum which can only be LEFT or RIGHT. But since compiler isn't smart enough and since I don't like these warnings, I'm making these default cases.

Reply

• May 26, 2016 - 01:36

-Wmisleading-indentation in 3rd party ofqf:

/home/e/MuseScore/thirdparty/ofqf/qoscserver.cpp:82: warning: this 'for' clause does not guard... [-Wmisleading-indentation]
                 for ( ; i < size && data[ i ] != char( 0 ); ++i )


/home/e/MuseScore/thirdparty/ofqf/qoscserver.cpp:85: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'for'
                while ( data[ i ] != ',' ) ++i;

Since this is 3rd party code, I'm wondering that making changes to this might not be the best, incase the 3rd party updates the code, then making comparisons will be difficult. But what I have done is use the auto indent feature in qtcreator, using musescore's coding rules .xml file, which will make comparisons easy against any new changes, provided that the new changes also use musescore's indentation rules.

Reply