Your opinion

[Richard Heathfield]

So an extern int printf(const char *, ...); is not required?

The prototype is indeed required. Perhaps Martin didn't notice that
<stdio.h> had not been included.

 

[Martin Ambuhl]

Nick Austin wrote:

The prototype is indeed required. Perhaps Martin didn't notice that
<stdio.h> had not been included.

Maybe Martin had posted even earlier a list of 6 errors, fully explaned,
including this one. What Martin didn't know was that Nick Austin just
threw in 1-line sentence fragments that tell nothing to the poster unless
he already knew what was wrongwhile expecting the posted code to not be fragmentary (a true sign of an
egocentric), and that Nick Austin used a news server that didn't observe
cancel requests (the cancel was sent within 5 seconds of my posting).

Perhaps Nick Austin should take a remedial writing course and change to a
non-broken news server.

 

[Bigdakine]

Subject: Your opinion

From: Ravi (e-mail address removed)
Date: 9/22/03 6:18 AM Hawaiian Standard Time
Message-id: <[email protected]>

#define A B
#define B A

main()
{
int A=5;
float B=6.0;
printf("\n %d %f",A,B);
printf(" %d %f",B,A);
}

Take a look at this program. What is the output?
Is it implementation dependent?

Never the lack of #include<stdio.h>

or int main() or having a return statement at the end of main..

But the macros simply mean that when the code is compiled A and B are
switched..

So that as far the compiler is concerned the code is :

main()
{
int B=5;
float A=6.0;
printf("\n %d %f",B,A);
printf(" %d %f",A,B);
}

Since B is an integer and A is a float the first printf should return:

5 6.00000

In the second printf you run into trouble, because A is a float, not an int.
Hence the second printf won't cause the code to bomb, but it will not behave in
a defined manner.

Compiling it as is should generate a few warnings which may be implementation
specific, but the results of the last printf should be gibberish no matter what
you run it on..

As to what it was desinged to test, I have no idea.

At least thats my 2cents.

Hope I past whatever it was..

Stuart

 

[Ben Pfaff]

But the macros simply mean that when the code is compiled A and B are
switched..

No, it doesn't. Try a C preprocessor. The macros are no-ops.

 

[Nils Petter Vaskinn]

One more redicilous question:
#define scanf "%s is a string"
void main()
{
printf(scanf,scanf);
}
What's the output?

Assuming that printf has been declared as usual and the compiler is borken
and accepts void main() I'd expect

%s is a string is a string

 

[Ravi]

Assuming that printf has been declared as usual and the compiler is borken
and accepts void main() I'd expect

%s is a string is a string

And can you explain how you come to this conclusion?
Do you think it is a good question? (Of course assume it was asked
with the header included and was int main and returned etc.)

 

[Arthur J. O'Dwyer]

int main(void)

And can you explain how you come to this conclusion?

Well, the preprocessor might expand the two 'scanf' parts to

printf("%s is a string", "%s is a string");

(although AFAIK it's not required to, since #defining scanf
and then #including <stdio.h> I think causes undefined behavior).

And it's obvious what *that* line prints, if it compiles. The
"%s" is the printf format specifier for "character string".

Do you think it is a good question? (Of course assume it was asked
with the header included and was int main and returned etc.)

Of course not!

-Arthur

 

[Martin Ambuhl]

Subject: Your opinion
From: Ravi (e-mail address removed)
Date: 9/22/03 6:18 AM Hawaiian Standard Time
Message-id: <[email protected]>

#define A B
#define B A

main()
{
int A=5;
float B=6.0;
printf("\n %d %f",A,B);
printf(" %d %f",B,A);
}

[...]
But the macros simply mean that when the code is compiled A and B are
switched..

This is wrong, wrong, wrongity wrong.

So that as far the compiler is concerned the code is :

No, 'tis'nt. 'Tis:

main()
{
int A = 5;
float B = 6.0;
printf("\n %d %f", A, B);
printf(" %d %f", B, A);
}

Ask Don Pop about details on thinking before you post. The #defines make
no effective change in the code.

 

[Richard Heathfield]

Assuming that printf has been declared as usual and the compiler is borken
and accepts void main()

Compilers are free to accept, reject, or twist void main programs at their
discretion (or indiscretion). A compiler is not broken just because it
accepts a broken program.

I'd expect

%s is a string is a string

Would you? The behaviour is undefined, not only because of void main() but
also because the program calls a variadic function - printf - without a
valid function prototype in scope.

 

[Richard Heathfield]

Maybe Martin had posted even earlier a list of 6 errors, fully explaned,
including this one.

Yes, you did. I had actually read it, too - albeit some while earlier - so I
have no excuse whatsoever for calling your attention to detail into
question. My apologies.

 

[Micah Cowan]

I don't get it. Why would d) be expected ?

None of the answers make any real sense, but d) seems the easiest
conclusion to arrive at if you have a *very* broken conception of how
C works. I would not expect (in the real world) any of the above, but
instead garble for some of the values, with a possible runtime
crash. Any of a through d, obviously, is possible (theoretically), and
none are more correct than the others...

-Micah

 

[Micah Cowan]

What's worse it had void main() originally and also a clrscr()
somewhere in between.

And the funniest part:
"What is the output on compiling the program:"
When they actually meant running the program.

LOL
And they think they are testing someones technical skill.

One more redicilous question:
#define scanf "%s is a string"
void main()
{
printf(scanf,scanf);
}

What's the output?
I think the output of this is not certain as well.

Actually, the output is very certain, provided that the prototype for
main() is fixed, and appropriate headers #included.

%s is a string is a string

Is what I would expect.

-Micah

 

[Christian Bau]

None of the answers make any real sense, but d) seems the easiest
conclusion to arrive at if you have a *very* broken conception of how
C works. I would not expect (in the real world) any of the above, but
instead garble for some of the values, with a possible runtime
crash. Any of a through d, obviously, is possible (theoretically), and
none are more correct than the others...

The macro usage is complicated enough that I don't care what the macros
do; code doing this kind of thing has to be changed. If I had to write a
C preprocessor or a C compiler then I would study what the C Standard
says and do The Right Thing whatever that is, but since I don't write C
preprocessors it is completely unnecessary to know what this does. Run
it through a compiler if you want to know.

Assuming that the macros A and B produce different replacement text, the
second printf would have undefined behaviour even _if_ the right header
file had been included. Since it hasn't been included, both printf calls
have undefined behavior and compilers that I use will _not_ produce any
meaningful results.

 

[Christian Bau]

Actually, the output is very certain, provided that the prototype for
main() is fixed, and appropriate headers #included.

%s is a string is a string

Is what I would expect.

scanf is quite possibly a macro defined in stdlib.h, and in that case
the #define will give an error because you attempt to redefine the
macro.

 

[Nils Petter Vaskinn]

And can you explain how you come to this conclusion?

I said assuming printf has been declared as usual. I should have added
"without using #include <stdio.h> to do it, so that the macro doesn't
crash with scanf"

I also said assuming void main() is accepted. I should have added "and the
compiler defines the behaviour as the same as for int main() without a
return."

And assuming that the platform flushes stdout for you, or fflush(stdout)
is added to main (after fflushaving been declared).

Basically if all the problems are fixed I'd expect

%s is a string is a string

Do you think it is a good question? (Of course assume it was asked with
the header included and was int main and returned etc.)

No!

Actually the unchanged original is a better question, as a trick question
mind, because of the "spot the error" factor.

 

[Mantorok Redgormor]

No, it doesn't. Try a C preprocessor. The macros are no-ops.

Why does this perform no operation? What am I missing?

I thought the following:

#define A B
#define B A

worked by first replacing all As' with Bs' then all Bs' with As' but
that is not how this works. Why is this?

 

[Richard Bos]

No, it doesn't. Try a C preprocessor. The macros are no-ops.

Never having thought seriously about such pathological code, this
surprised me, but let me try to explain this to myself: even though
6.10.3.4 starts with "After all parameters in the replacement list have
been substituted", that whole section, including #2, actually applies to
object-like as well as to function-like macros. Right?
And therefore, wherever an A is encountered in the source code, this is
replaced by a B, which is replaced by an A, which, having already been
processed, is not replaced again; and when a B is encountered, the same
procedure is followed, thus B is replaced by A, which is replaced by B,
which is not re-replaced.

Richard

 

[Irrwahn Grausewitz]

Ask Don Pop about details on thinking before you post.

^
Is this a typo or a joke?

Irrwahn

 

[Dan Pop]

I don't get it. Why would d) be expected ?

Because that's what you get on a typical x86 implementation ;-)

Dan

 

[Dan Pop]

Actually, the output is very certain, provided that the prototype for
main() is fixed, and appropriate headers #included.

Is it?

%s is a string is a string

Is what I would expect.

C99 7.1.3 Reserved identifiers:

- Each identifier with file scope listed in any of the following
subclauses (including the future library directions) is
reserved for use as a macro name and as an identifier with
^^^^^^^^^^^^^^^
file scope in the same name space if any of its associated
headers is included.

OTOH, even a C89 implementation can define the macro scanf if
<stdio.h> is included, so, the code, with your suggested fixes, may not
work there, either.

Then, we have the issue of the last line of output not being newline
terminated...

The proper way of fixing the code is:

#define scanf "%s is a string"
int printf(const char *format, ...);
int putchar(int);

int main()
{
printf(scanf, scanf);
putchar('\n');
return 0;
}

The true pedant would also attempt to fix the "restrict" issue in the
printf prototype ;-)

Dan