[Development] Compiler warnings

Mathias Hasselmann mathias at taschenorakel.de
Fri Oct 17 14:52:46 CEST 2014



Am 17.10.2014 um 13:16 schrieb Kurt Pattyn:
>
>> On 17 Oct 2014, at 12:54, Sean Harmer <sean.harmer at kdab.com> wrote:
>>
>> On 17/10/2014 11:44, Bo Thorsen wrote:
>>> Den 17-10-2014 12:22, Julien Blanc skrev:
>>>> On 17/10/2014 10:15, Christian Kandeler wrote:
>>>>> On 10/17/2014 08:48 AM, Kurt Pattyn wrote:
>>>>>> As we are developing for aerospace, avionics, defence and healthcare, we are confronted on a daily basis with a lot of very stringent rules that we have to comply with (irrespective if some people might find these rules outdated, stupid, ridiculous or not). That's why we always compile with as much compiler warnings as possible. Our code must be audited by an external office anyways, so we better make sure we can avoid a bad report as soon as possible.
>>>>>> Some examples of 'stupid' rules (which after second consideration aren't that stupid after all):
>>>>>> - a switch statement must always have a default statement (also all cases must be handled)
>>>>> Doesn't this actually make the code *worse* when using enums? Adding a
>>>>> default statement when you handle all possible values will inhibit
>>>>> genuine compiler warnings when you forget to add a case for a newly
>>>>> added enum value. In fact, this is almost guaranteed to happen in a
>>>>> non-trivial project, so this rule seems almost absurdly wrong to me.
>>>> That one is always subject to debate. There is one thing not to forget
>>>> in favor of this rule : enums are *not* guaranted to have a value
>>>> amongst the defined ones. Undefined behaviour in that case is not an option.
>>>>
>>>> I wish i could have both a default statement and my compiler warning…
>>> switch (enumValue) {
>>> case E1: ...; break;
>>> case E2: ...; break;
>>>
>>> case Nope1:
>>> case Nope2:
>>>     // Intentionally not handled
>>>     break;
>>> }
>>>
>>> Boom. Can I invoice you for this now? :)
>>
>> See also, Q_UNREACHABLE().
> Indeed, but the main reason that all cases must be handled is to avoid arbitrary crashes of an application.
> And handling does not mean just adding comments. We cannot afford that an X-Ray scanner crashes while beaming its X-rays onto a patient.
> We cannot afford that a Boeing goes down because the software just crashes.
> We speak of life critical applications here; in all other cases, most of these measures are merely overkill.
> Q_UNREACHABLE() is fine if we can *prove* that indeed it will never be reached; the latter being nearly impossible.

It's not only life critical systems. It's already if you want your 
software to appear as high quality, that do graceful error recovery.
Anyway, my default pattern to get compiler warnings while also handling 
unexpected values:

     auto supportFunction(Enum value)
     {
         switch (value) {
         case Foo:
             handleFoo();
             return ...;

         case Bar:
             handleBar();
             return ...;
         }

         logErrorCondition();
         runGracefulFallbackAction();
     }

The major trick is to use return instead of break. Brave people might 
use a goto instead of that return and that support function, I don't.

Ciao,
Mathias



More information about the Development mailing list