0

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
5
  • 7
    boolean logic: FALSE || TRUE always yields TRUE, from the very definition of "or".
    – BobDalgleish
    Aug 20, 2014 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, 2014 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, 2014 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, 2014 at 3:12
  • if (TRUE) isn't functionally equivalent, despite it having the same outcome to the "if" statement.
    – jwenting
    Sep 3, 2014 at 8:09

4 Answers 4

Reset to default
4

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
3

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
  • 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, 2014 at 17:12
2

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
1

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
1
  • I would suggest looking up Nick Krause linux on google. The code is intentionally smelly and trying to be obscure.
    – user40980
    Sep 14, 2014 at 1:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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