-1

New to C programming. Why the output of this code below is not 0 20 0 but instead it is 1 20 0?

printf ( "\n%d %d %d", x != 1, x = 20, x < 30 ) ;

My understanding is that the code is assigning x to a value other than 1 (1=true therefore != true is 0)? Can someone walk me through the logic?

Curious Student
  • 70
  • 1
  • 6
Fatima Zolfaghar
  • 11

1 Answers1

7

I don't know why it's so popular for some educational systems to pick ever more inventive ways to teach bad code with unspecified behaviour, but since the order of evaluating those arguments is unspecified, the behaviour of your program is undefined.

That is, you may be assuming that the code is "run" left-to-right, or right-to-left, but no such thing is required. In fact, anything can happen, including any output or the murder of any of my family. So please don't!

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
  • It is not true that anything can happen. The only power of the C standard, or other specifications, is to define or withhold definition. They are unable to license violations of other documents or of laws of nature, mathematics, or humans. Phrasing it this way conveys a notion that the behavior of a program whose behavior is not defined by the C standard cannot be analyzed and hence cannot be debugged. But that is not true. The behavior of a faulty program, including its output, traps, and memory dump, may contain clues that, interacting with the designs of compilers and more, aid diagnosis. – Eric Postpischil Feb 18 '19 at 23:22
  • 2
    Better phrasing is simply to say that “The C standard does not define the behavior.” – Eric Postpischil Feb 18 '19 at 23:23
  • 3
    @EricPostpischil Undefined behavior can be pretty scary though. There's an example program that executes a function even though no code explicitly calls it, because that function call is only path that is not undefined behavior. Therefore the compiler assumes that function pointer must be set and that function must be called. The danger is real. Some danger anyway. It would depend on what that code that is never called (hah) does. – Zan Lynx Feb 18 '19 at 23:25
  • 1
    @EricPostpischil It's vanishingly unlikely to happen, though more likely then the proverbial nose-demons. Nevertheless, no guarantees at all means *exactly that*! – Deduplicator Feb 18 '19 at 23:30
  • @ZanLynx: A treatment for fear is knowledge. That bit about a function apparently not being called being called is actually quite sensible once one becomes familiar how optimizers work. It seems strange and puzzling the first time one hears about it, but later it falls into place and becomes a tool for understanding programs, compilers, optimizers, formal semantics and software generally, and it improves one’s ability to diagnose failures. – Eric Postpischil Feb 18 '19 at 23:35
  • @Deduplicator: What is vanishingly unlikely to happen? I did not give any examples of behavior that could happen except that there could be clues in the behavior. That is not vanishingly unlikely to happen; the misbehavior of a program is often a huge clue about what went wrong. – Eric Postpischil Feb 18 '19 at 23:36
  • 2
    @EricPostpischil Please refer to my final paragraph [here](https://stackoverflow.com/a/49032606/560648). Analysing the reasons for a particular "case" of UB [can absolutely be fascinating and educational](https://stackoverflow.com/q/54120862/560648) but, honestly, there's a time and a place for that and in my judgement this is not it. Of course, feel free to write a contrasting answer! – Lightness Races in Orbit Feb 18 '19 at 23:47
  • I suppose we could also phrase this as "_not quite anything can happen_ is a valid manifestation of the rule that _anything can happen_" ;) – Lightness Races in Orbit Feb 19 '19 at 00:00
  • `int` overflow --> trap --> [$500 million loss](http://www-users.math.umn.edu/~arnold/disasters/ariane.html). – chux - Reinstate Monica Feb 19 '19 at 01:09