home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c      Meh, in C you gotta define EVERYTHING      243,242 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 241,416 of 243,242   
   Janis Papanagnou to David Brown   
   Re: bugprone-switch-missing-default-case   
   23 Oct 25 04:39:17   
   
   From: janis_papanagnou+ng@hotmail.com   
      
   On 22.10.2025 17:25, David Brown wrote:   
   > On 22/10/2025 15:56, Janis Papanagnou 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?   
   >>>>   
   >>>> 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.   
   >>>>   
   >>> Use an enum, and the compiler will warn you ...   
   >>   
   >> Maybe. Although I don't recall that the "C"-compilers I formerly   
   >> used checked enums as you've shown below. - But anyway...   
   >>   
   >> Enums don't help if you use and compare against (for example)   
   >> characters that are (for example) got from an external source.   
   >>   
   >>    char * cmds = "CMDQ";    // 'D' maybe added later   
   >>    char cmd;   
   >>    ...some n lines of code...   
   >>    ...get input cmd...   
   >>    ...optionally verify cmd with cmds...   
   >>    ...some more m lines of code...   
   >>    switch (cmd) {   
   >>    case 'C': ...;   
   >>    case 'M': ...;   
   >>    default: printf ("Error: uncaught cmd '%c'\n", cmd);   
   >>    }   
   >>   
   >> It's good to take precautions and define the 'default' case. YMMV.   
   >>   
   >   
   > That's not "taking precautions".  If the "...optionally verify cmd" part   
   > does a good job, then the default line is worse than useless because it   
   > is code that never runs. [...]   
      
   Not sure what you expect in that line. I've had something like   
     strchr (cmds, cmd)  in mind. And the 'switch' is independent   
   of that, so you could miss adding the switch branch of a later   
   added command character.   
      
   The point was that mistakes can be made, not only in the initial   
   implementation but also if it gets extended later, and probably   
   by other folks than the original implementer. I also gave a hint   
   with "...some more m lines of code..." that such omissions may   
   also be hard to spot.   
      
   It is experience from professional real life projects that such   
   things happen. And blaming anyone that he's not done "a good job"   
   may be the appropriate diagnosis and important point if what you   
   want is primarily to blame someone, but if you want software to   
   get developed reliably, one element is to quickly spot the place   
   of such omissions.   
      
   Janis   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca