I got lost in the opening of this post on reddit.

How can if (sscanf(buf, "%i", &mode) != 1 || TRUE) be rewritten to if (TRUE)? Does this assume that the sscanf never fails?

| improve this question | | | | |
  • 7
    boolean logic: FALSE || TRUE always yields TRUE, from the very definition of "or". – BobDalgleish Aug 20 '14 at 16:58
  • If the processing inside the if statement uses the data located in buf, then yes we assume sscanf never fails. – Cameron McKay Aug 20 '14 at 17:00
  • 2
    It cannot be rewritten as just "if (TRUE)", because you DO need to do the scanf first as well (as the original post on reddit showed, but that detail was not included in the question here) for the code to be functionally identical. However, the test will always evaluate to true as mentioned by @BobDalgleish and others. – mc110 Aug 21 '14 at 15:56
  • It's probably debug code to force the branch condition. It's after the sscanf because of short-circuiting semantics. Someone might write this code over other changes because it is presumably faster to test out a quick hack. – Thomas Eding Aug 22 '14 at 3:12
  • if (TRUE) isn't functionally equivalent, despite it having the same outcome to the "if" statement. – jwenting Sep 3 '14 at 8:09

The author of the code calls sscanf and then ignores its return value assuming it is true. You can replace the code with 'if (TRUE)' provided that you call sscanf first.

| improve this answer | | | | |

Using truth tables, you can show it will always return -EINVAL, thus, don't even need the

if (TRUE)
   return -EINVAL;

it could be just

return -EINVAL

FWIW, since I don't have the context, this is almost certainly a bug. The

(mode != 2 || mode != 1)  

probably should have been

(mode != 2 && mode != 1)
| improve this answer | | | | |
  • 1
    Correct. I guess this is code from a guy trolling and screwing up the kernel. Linux blacklisted him, but somehow this seeped in. – floopdagoop Aug 20 '14 at 17:12

I think it's assuming that even if sscanf does fail, it doesn't care.

Since the result is being ignored, I don't see the point of having this within the "if" at all. I would guess that the sscanf call was originally on its own, then duff data started arriving (in buf) and messing up the sscanf call, so the "|| TRUE" was added to suppress the error. Classic, Quick and Dirty fix.
Personally, I'd prefer to see this reworked:

sscanf( buf, "%i", &mode ); /* buf may or may not contain a valid mode */ 

Of course, the data item addressed by &mode might well be left in an inconsistent state - possibly a value parsed from buf, possibly not - but this code doesn't care either way.

| improve this answer | | | | |

Surely this is a smell? Using 'OR true' in a conditional statement is jarring to read and of no functional value.

if(statement OR true) { ... } would be better written as statement; { ... } ?

| improve this answer | | | | |
  • I would suggest looking up Nick Krause linux on google. The code is intentionally smelly and trying to be obscure. – user40980 Sep 14 '14 at 1:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.