Description of problem: I just tried to compile package configure-thinkpad-0.9-1 from Redhat Fedora Extras development tree. The compiler said callbacks.c(536): warning #1011: missing return statement at end of non-void function "to_timer" The source code is static int to_timer(int power_mode, int battery_p) { switch (power_mode) { case 0: return(TIMER_HIGH); case 1: return(TIMER_AUTO); case 2: if (battery_p) { return(TIMER_MANUAL_BATTERY); } else { return(TIMER_MANUAL_AC); } } } Suggest add code to deal with the case where power_mode is < 0, or > 2. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Bug report forwarded upstream to (wang02139 at gmail.com), asking him what's the proper way to fix this.
After a brief look at the code, I'd say a fix would be purely cosmetical as it would only please the compiler. If function to_timer(..) is never called with a first argument outside [0,1,2], the function need not have a catch-all rule. If it were ever called with an arg outside [0,1,2], that would be a bug somewhere else. Some programmers like to shut up compilers and get rid of all warnings, others do not.
>If it were ever called >with an arg outside [0,1,2], that would be a bug somewhere else. By adding code to the function to detect arguments with bad values, you make the function more robust. Certainly, silently returning rubbish to the caller is a dangerous policy.
> By adding code to the function to detect arguments with bad values, > you make the function more robust. No, you refer to the purely theoretical scenario that the function would actually be called with an argument outside its well-defined domain. If that happened, that would be unexpected/undefined behaviour. Would the change in the function be semantically correct? To return a good value for illegal input? Simply altering the function's domain doesn't make anything more robust. Just read the source code and notice where the programmer has placed related assertions during development. I don't refer to the general case of catch-all rules or default statements as necessary for a well-defined range of return-values, I refer to this particular program.
FC3 and FC4 have now been EOL'd. Please check the ticket against a current Fedora release, and either adjust the release number, or close it if appropriate. Thanks. Your friendly BZ janitor :-)
Fedora Core 3 is not maintained anymore. Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the current Fedora release please reopen this bug and assign it to the corresponding Fedora version.