EmbeddedRelated.com

(So far, 1850 people got it right out of 2786 for a success rate of 66%)

Predict the output of the following C program.

#include <stdio.h>
#define x 2+3
int main()
{
    int y;
    y = x*x*x;
    printf("%d", y);
    return 0;
}
Pick one:
8
125
17
None of the above


[ - ]
Comment by stephanebOctober 22, 2019

What do you think, do you agree with the solution/explanation?

[ - ]
Comment by federouxOctober 23, 2019

I agree with the solution, but I think that maybe this quiz is only about C language. To make a quiz about embedded systems I would answer, for example, about different variables definitions (local, global, initalizated, malloc) and their localization (stack, heap, data, bss)...what do you think?

[ - ]
Comment by dcblackOctober 23, 2019

It is also interesting to consider aspects such as C/C++ incompatibilities, concurrency issues, bare metal vs RTOS vs Linux (and the underlying hardware requirements/differences), the use of other languages (e.g. Python).

[ - ]
Comment by rubinstuOctober 23, 2019

If this were an interview question, what's more important is the follow-up: "Is this bad code? Why? What would you do to fix it, if anything?" Even experienced C programmers who would catch this "problem" immediately would have structured the code with parentheses, etc., to be more explicit on the page, even if the end resulting binary were the same.

[ - ]
Comment by stephanebOctober 24, 2019

Many people on Linkedin have complained as well about how bad this code is.  If you were to re-write this code in a way that most Embedded Systems engineers would agree is following best practices, how would it look?

[ - ]
Comment by aaronbauchOctober 23, 2019

One of my favorite quotes goes something like:

"Which has higher precedence, || or & in C?"

The correct answer is "Who cares?!!!"  If you have to ask you are writing bad code.  Use parentheses liberally to make your intent clear.  They are free!

[ - ]
Comment by NusaCatJanuary 18, 2023

While you have a point, you may also be missing the point. I don't have a problem with my own code, but I've spent a lot of time looking at code someone else wrote. It's important to understand the rules of the game, like order of precedence, if you want to understand what actually is happening.

The quick fix in this particular instance is to change the define to either: #define x (2+3)   -or-  #define x 5  even if that isn't the approach you would take starting from scratch.

[ - ]
Comment by ee361taOctober 24, 2019

Well, the answer is 0 depending on your semantics. The question asks for the "output". Now, the output of the function is 0, because you "return 0". If you are asking what is printed to the output stream, then the answer is what is stated. I wasn't sure if this was a trick question. For all those that chose "None of the above" because of this, I got your back. ;)

[ - ]
Comment by occam25July 15, 2022

Not really.. here the "output" of the program is what it prints out to the standard output. Zero is the return/exit value. 

[ - ]
Comment by MatthewEshlemanJuly 18, 2022
Ideally the answer is perhaps: Please never write code like this: avoid preprocessor magic entirely.

However, as others are noting, and for new software developers, the key point is to remember that the preprocessor hits (effectively edits) the code before the compiler actually compiles it.

FYI: You can play with the answer here: https://godbolt.org/z/h6rqredPY 

So: 

x*x*x 

is expanded (without any 'smarts') by the preprocessor to:

2+3*2+3*2+3 

When the code executes, we get:

2+(6)+(6)+3 

or

8+9 = 17

But again, please do not use #define macros in this manner. Use 'const' and 'constexpr' where possible. This will ensure type safety and also help avoid unexpected results due to accidental missing parans.

Hope that helps!

Best regards,

Matthew

https://covemountainsoftware.com/


[ - ]
Comment by stephanebJuly 18, 2022

Thanks!

[ - ]
Comment by mwrJuly 14, 2022

A better solution would be to add a "++" after that "C", and make friends with constexpr.

[ - ]
Comment by PripawarOctober 23, 2019

We can add more architectural and OS related questions. These will help for block level understanding. 

[ - ]
Comment by mr_banditOctober 23, 2019

This is the reason I insist on parens to avoid the issue of precedence.

For a really bad example, look at the library code for time_t calculation - depends totally on precedence.

I wannt to know how many folks copied the code & compiled/ran it - I did. While the precedence in C is well-defined, it is error-prone to try to figure out how it applies.

[ - ]
Comment by snn1989December 5, 2019

Sensible.

To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.

Please login (on the right) if you already have an account on this platform.

Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers: