From: antispam@fricas.org   
      
   David Brown  wrote:   
   > On 22/10/2025 16:05, Janis Papanagnou wrote:   
   >> On 22.10.2025 15:41, David Brown wrote:   
   >>> On 22/10/2025 13:44, Richard Harnden wrote:   
   >>>> On 22/10/2025 10:32, Janis Papanagnou wrote:   
   >>>>> On 22.10.2025 10:56, pozz wrote:   
   >>>>>>   
   >>>>>>> Switch statements without a default case can lead to unexpected   
   >>>>>>> behavior and incomplete handling of all possible cases. When a switch   
   >>>>>>> statement lacks a default case, if a value is encountered that does   
   >>>>>>> not match any of the specified cases, the program will continue   
   >>>>>>> execution without any defined behavior or handling.   
   >>>>>>   
   >>>>>> Maybe I misunderstood that sentence caused by my bad English. I knew   
   >>>>>> that in case the switch value is not present in any case inside the   
   >>>>>> switch, the program continues without doing anything (in the switch)   
   >>>>>> and   
   >>>>>> without any problem.   
   >>>>>>   
   >>>>>> int x = 3;   
   >>>>>> switch(x) {   
   >>>>>>     case 1: printf("Hello");break;   
   >>>>>>     case 2: printf("World");break;   
   >>>>>> }   
   >>>>>>   
   >>>>>> Will the program execution continue without any defined behaviour?   
   >>>   
   >>> Presumably you meant "without any undefined behaviour" ?  The code is   
   >>> fine - if no cases match and there is no default case, execution   
   >>> continues from the end of the switch statement.  Like most warnings,   
   >>> this is about a possible bug in the code - not a definite one.   
   >>>   
   >>>>>   
   >>>>> Your program fragment is well defined.   
   >>>>>   
   >>>>> What the poster certainly tried to express was that in case you   
   >>>>> haven't implemented a complete list of all possible cases and   
   >>>>> also not provided a 'default' to catch all non-specified cases,   
   >>>>> then you might get in troubles with your program, probably by   
   >>>>> possible oversights, future extensions, new data, and whatnot.   
   >>>>>   
   >>>>> Personally I have the habit to always define a default branch,   
   >>>>> and even if that default is impossible to reach you'll find an   
   >>>>> error message (like "internal error with unexpected value...")   
   >>>>> generated at that place.   
   >>>   
   >>> I don't think it is normally appropriate to add a default case unless   
   >>> you actually need it   
   >>   
   >> Yes I was saying that I want it; I "need" it once errors slip in and   
   >> such a message or error log immediately clears the issue! (You might   
   >> be excluding some "needs" from your repertoire of necessities, okay.)   
   >>   
   >>> - code that exists but can never be reached is   
   >>> untestable and can be confusing to people reading the code.  But   
   >>> sometimes it can be useful to add a "default : printf("Internal   
   >>> error...");" for debugging, however.   
   >>   
   >> This printf error message or log entry is what I suggested. It isn't   
   >> confusing because it even _documents_ what's the case here. Rather,   
   >> a missing default leaves the reader with an unnecessary uncertainty.   
   >> YMMV.   
   >>   
   >   
   > Indeed YMMV.  But when I see a printf call that says something has gone   
   > horribly wrong, I wonder /how/ that could happen.  I don't put such   
   > statements into my code without it being a possible execution path.   
      
   IME it is a possible execution path unless you have very simple   
   and carefully checked proof that it is not.  I mean, you may   
   _think_ that you proved that given case can not happen, but   
   once your argument gets complex there is realistic chance of   
   error in your proof.  That happened to myself, but I had code   
   like:   
      
       default:   
          ERROR("Impossible");   
      
   and well, "Impossible" happened.   
      
   > I   
   > agree, of course, that a good error message here makes the code somewhat   
   > self-documenting in terms of what it does.  But it does nothing to help   
   > say how it happened to run.  A printf call that never runs is not free -   
   > it costs in many different ways, and should not be there unless it is   
   > worth those costs.   
      
   That depends.  I one constext that means adding some tens of bytes   
   to binary, which is negligible given size to the thing of modern   
   PC-s.  Execution time usualy is negligible too (I do not have   
   switches in inner loops, so even if extra case leads to extra   
   comparison it does not matter much).  There is question of   
   consequences.  In my case unhandled case can easily lead to producing   
   wrong value, which is worst kind of error for the application.   
   Signaling error essentially means "can not do this" and is nothing   
   unusual.   
      
   In embedded context this is different, as you noted extra code   
   can exceed time budget.  Stopping device may not be an option   
   and there could be no way to print error message.  OTOH control   
   and date flow in embedded applications tend to be much simpler   
   than in PC applications, so chance of correct proof are better.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)