This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/53479] New: Control flow analysis too alarming with switch over an enum class


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479

             Bug #: 53479
           Summary: Control flow analysis too alarming with switch over an
                    enum class
    Classification: Unclassified
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: 0xd34df00d@gmail.com


Created attachment 27492
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27492
A very simple testcase

If a non-void function consists of a switch over a variable of an enum class,
and all possible values of the enum class are listed in the cases, and each
case ends with a return, gcc 4.6 and later still emits a "control reaches end
of non-void function" warning. gcc 4.5 and earlier don't exhibit such behavior
(as well as clang, if that matters). See the attached file for an example.

While this is a somewhat reasonable behavior for switches over a plain enum, I
doubt it is OK to emit this warning, at least, with such a generic option as
-Wreturn-type. If neither case succeeds, then you have had an UB somewhere in
your code previously, but I doubt it's good to warn the user in the switch.

Moreover, adding a 'default' clause allows to shoot yourself in the foot later
when adding one more field in the enum â the compiler won't warn you that you
didn't check it. Adding a dummy return after the switch seems more like a
kludge.

If there are strong considerations for this warning in this case, I suggest
moving it to a separate warning class, like -Wreturn-enum-class or something
like that. This way those who don't need this check will be able to disable it
without hurting other cases where it's useful for them.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]