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,417 of 243,242   
   Janis Papanagnou to David Brown   
   Re: bugprone-switch-missing-default-case   
   23 Oct 25 04:54:18   
   
   From: janis_papanagnou+ng@hotmail.com   
      
   On 22.10.2025 17:23, 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,   
      
   "has gone horribly wrong"? - It says nothing like that. - As I already   
   said it's an effective measure to be able to quickly spot errors that   
   slipped in.   
      
   > I wonder /how/ that could happen.   
      
   (In the world I live and worked in I saw mistakes and errors happen.)   
      
   > I don't put such   
   > statements into my code without it being a possible execution path.   
      
   (Do what you prefer in your personal context. - I don't mind.)   
      
   > I   
   > agree, of course, that a good error message here makes the code somewhat   
   > self-documenting in terms of what it does.   
      
   (Glad to hear you see and accept that.)   
      
   > But it does nothing to help say how it happened to run.   
      
   ??? - The example scenario will run. Just may have erroneous results   
   when triggering the case that isn't handled. With diagnostic records   
   you can quickly identify and fix it (usually in one of the QA test   
   cycles before you deliver the software).   
      
   > 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.   
      
   (You're obviously a better discussion candidate for folks who count   
   bytes and microseconds, say, like bart. - The "costs" that matters   
   much more in professional software development are quality and time.)   
      
   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