Your opinion

[Ravi]

#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?

Do you think this question aim's at analising a person's C skills?
(It was asked in a Technical skill paper)

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

[Ben Pfaff]

Ravi <[e-mail]> writes:

$ gcc -E temp.c
# 4 "temp.c"
main()
{
printf("\n %d %f",5,5);
printf(" %d %f",5,5);
}

If someone could help me understand this...

Please ask questions about your compiler in a newsgroup about
your compiler.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Micah Cowan]

Ravi <[e-mail]> writes:

On 23 Sep 2003 13:57:17 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <m3************@localhost.localdomain> Micah Cowan <mi***@cowan.name> writes:

Ravi <[e-mail]> writes:

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.

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 ;-)

But if we replace scanf with MACDEF will the code be acceptable?

Yes (again, assuming <stdlib.h> was #included or appropriate
prototypes are in place). But in C99, the "restrict" issue Dan Pop
refers to would still be an issue, resulting in potential undefined
behavior.

(To readers who may not have caught the "restrict" issue): The problem
is that identical string literals are not required to be unique: the
string literal by which MACDEF would be replaced might be stored in
the very same memory location for both. In C99, printf()'s format
string argument is declared with the "restrict" specifier, which means
essentially that you promise not to pass it another pointer into the
same object. That promise would be violated by the above code (not to
mention that the printf() protype Dan stuck in there wouldn't be valid
anymore, either, as it lacks the "restrict" specifier).

-Micah

[Alex]

Ravi <[e-mail]> wrote:

On Wed, 24 Sep 2003 00:50:43 +0530, Ravi <[e-mail]> wrote:

On Tue, 23 Sep 2003 18:12:51 +0000 (UTC), Andreas Kahari
<ak*******@freeshell.org> wrote:

Or you can also tell me how it can be done on a Linux machine with all
standard development tools installed.

On all systems with the GNU Compiler Collection (GCC) installed
(almost any popular OS I can think of can run GCC):

gcc -E file.c

You've got TFM, now R it.

Thanks for the kind reply.

$ cat temp.c
#define A B
All instances of 'A' are now 'B'
#define B A
All instances of 'B' are now 'A'
#define A 5
All instances of 'A' are now '5'
main()
{
printf("\n %d %f",A,B);
printf(" %d %f",B,A);
} $ gcc -E temp.c
# 4 "temp.c"
main()
{
printf("\n %d %f",5,5);
printf(" %d %f",5,5);
} If someone could help me understand this...

What is confusing you?

Alex

[Micah Cowan]

Ravi <[e-mail]> writes:

$ cat temp.c
#define A B
#define B A
#define A 5
At this point, any behavior we discuss is off-topic, as you now have
undefined behavior by #defining the same symbol twice with different
replacement lists. However...
main()
{
printf("\n %d %f",A,B);
printf(" %d %f",B,A);
}

$ gcc -E temp.c
# 4 "temp.c"
main()
{
printf("\n %d %f",5,5);
printf(" %d %f",5,5);
}

If someone could help me understand this...

What's to understand? A and B have been replaced by their replacement
lists (which happens to be 5 for both of them). As to why it's 5, no
one can answer that, since it was undefined behavior to begin with. If
you're wondering about the first line, that's not C, it's special
symbols the preprocessor sends to hte compiler to tell it where the
rest of the code came from (since it snipped some lines which were
preprocessor directives).

-Micah

[Arthur J. O'Dwyer]

On Tue, 23 Sep 2003, Micah Cowan wrote:

Ravi <[e-mail]> writes:

On 23 Sep 2003 13:57:17 GMT, Da*****@cern.ch (Dan Pop) wrote:

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

But if we replace scanf with MACDEF will the code be acceptable?

Yes (again, assuming <stdlib.h> was #included or appropriate
prototypes are in place). But in C99, the "restrict" issue Dan Pop
refers to would still be an issue, resulting in potential undefined
behavior.

(To readers who may not have caught the "restrict" issue): The problem
is that identical string literals are not required to be unique: the
string literal by which MACDEF would be replaced might be stored in
the very same memory location for both. In C99, printf()'s format
string argument is declared with the "restrict" specifier, which means
essentially that you promise not to pass it another pointer into the
same object. That promise would be violated by the above code (not to
mention that the printf() protype Dan stuck in there wouldn't be valid
anymore, either, as it lacks the "restrict" specifier).

Wait... so does standard C99 really make it unspecified whether

char *mystring = "%s";
printf("%s", mystring);

invokes undefined behavior? Pardon me, but that's just crazy.
I don't immediately see how to fix it, other than mandating
that each compiler make sure for themselves that string literals
don't interfere with any 'restrict' issues.

-Arthur,
learning something horribly new every day

[Keith Thompson]

[...]
#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);
}

Q: What does this program do?

A: It gets re-written.

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Ben Pfaff]

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

Wait... so does standard C99 really make it unspecified whether

char *mystring = "%s";
printf("%s", mystring);

invokes undefined behavior? Pardon me, but that's just crazy.
I don't immediately see how to fix it, other than mandating
that each compiler make sure for themselves that string literals
don't interfere with any 'restrict' issues.

I don't think that this code is undefined in C99. Check out
example 3 in C99 6.7.3.1:

10 EXAMPLE 3 The function parameter declarations
void h(int n, int * restrict p, int * restrict q, int * restrict r)
{
int i;
for (i = 0; i < n; i++)
p[i] = q[i] + r[i];
}
illustrate how an unmodified object can be aliased through two restricted pointers. In particular, if a and b
are disjoint arrays, a call of the form h(100, a, b, b) has defined behavior, because array b is not
modified within function h.

printf() doesn't modify its arguments[1] so I don't think that
printf("%s", "%s"); is undefined.

Or am I missing something?

[1] Well, certainly not in this case, unless you want to argue
that one should not pass string literals to printf().
--
A competent C programmer knows how to write C programs correctly,
a C expert knows enough to argue with Dan Pop, and a C expert
expert knows not to bother.

[Bigdakine]

>Subject: Re: Your opinion

From: Ben Pfaff bl*@cs.stanford.edu
Date: 9/22/03 7:01 PM Hawaiian Standard Time
Message-id: <87************@pfaff.stanford.edu>

bi*******@aol.comGetaGrip (Bigdakine) writes:

>From: Ravi [e-mail] >#define A B
>#define B A
>

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.

You're absolutely right. My mistake.

Stuart

[Bigdakine]

>Subject: Re: Your opinion

From: Ravi [e-mail]
Date: 9/23/03 7:04 AM Hawaiian Standard Time
Message-id: <a8********************************@4ax.com>

On 23 Sep 2003 04:06:22 -0700, ne*****@tokyo.com (Mantorok Redgormor)
wrote:

Ben Pfaff <bl*@cs.stanford.edu> wrote in message

news:<87************@pfaff.stanford.edu>...

bi*******@aol.comGetaGrip (Bigdakine) writes:

> >From: Ravi [e-mail]

> >#define A B
> >#define B A
> >

> 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.

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

#define A B
#define B A
int main(void)
{
B;
return 1;
}

on compiling:
Error 7: Undefined symbol 'B'
_____________

//#define A B
#define B A
int main(void)
{
B;
return 1;
}

On compiling:
Error 7: Undefined symbol 'A'

This might make thing clear :)

Actually no. THis has nothing to do with the macros. In your code " B ;"
doesn't make sense. B has no type and is hence undefined. So when it is
replaced by A, it is still undefined.

My mistake was in thinking that the preprocessor didn't make recursive
substitutions.

Course, I wouldn't try that example in real life.

Stuart
Dr. Stuart A. Weinstein
Ewa Beach Institute of Tectonics
"To err is human, but to really foul things up
requires a creationist"

[Mark McIntyre]

On Tue, 23 Sep 2003 23:16:10 +0530, in comp.lang.c , Ravi
<[e-mail]> wrote:

On 23 Sep 2003 17:34:22 GMT, Da*****@cern.ch (Dan Pop) wrote:

Do yourself a favour and learn how to obtain the preprocessor's output:
it's much easier to solve preprocessing issues this way than by
examining compiler error messages.

How would I do that on Turbo C++?

either by reading the manual, or by asking in a TC group, or by typing
in TC /?

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>

[Mark McIntyre]

On Tue, 23 Sep 2003 13:16:18 +0200, in comp.lang.c , Irrwahn
Grausewitz <ir*****************@freenet.de> wrote:

Martin Ambuhl <ma*****@earthlink.net> wrote:
<SNIP>

Ask Don Pop about details on thinking before you post.

^
Is this a typo or a joke?

Don is Dan's twin brother - Don got the people skills, Dan the C
skills... :-)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>

[Keith Thompson]

bi*******@aol.comGetaGrip (Bigdakine) writes:
[...]

#define A B
#define B A
int main(void)
{
B;
return 1;
}

on compiling:
Error 7: Undefined symbol 'B'
_____________

//#define A B
#define B A
int main(void)
{
B;
return 1;
}

On compiling:
Error 7: Undefined symbol 'A'

This might make thing clear :)

Actually no. THis has nothing to do with the macros. In your code " B ;"
doesn't make sense. B has no type and is hence undefined. So when it is
replaced by A, it is still undefined.

The point, I think is that the compiler's error message, "Undefined
symbol 'B'" or "Undefined symbol 'A'", tells you what the symbol B was
ultimately replaced with by the preprocessor. Presumably the part of
the compiler that complains about undefined symbols runs after the
preprocessor (and doesn't have any visibility to the un-preprocessed
source).

It's an odd way of figuring out what the preprocessor is doing, but it
works in this case.

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Micah Cowan]

Ben Pfaff <bl*@cs.stanford.edu> writes:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

Wait... so does standard C99 really make it unspecified whether

char *mystring = "%s";
printf("%s", mystring);

invokes undefined behavior? Pardon me, but that's just crazy.
I don't immediately see how to fix it, other than mandating
that each compiler make sure for themselves that string literals
don't interfere with any 'restrict' issues.
I don't think that this code is undefined in C99. Check out
example 3 in C99 6.7.3.1:

<snipped example>
printf() doesn't modify its arguments[1] so I don't think that
printf("%s", "%s"); is undefined.

Or am I missing something?

[1] Well, certainly not in this case, unless you want to argue
that one should not pass string literals to printf().

Yeah, okay, that sounds right. In that case, Dan, what *was* the
issue? Or were you thinking the same way? Or was the "restrict issue"
the misdeclaration of printf()?

-Micah

[Dan Pop]

In <m3************@localhost.localdomain> Micah Cowan <mi***@cowan.name> writes:

Yeah, okay, that sounds right. In that case, Dan, what *was* the
issue? Or were you thinking the same way? Or was the "restrict issue"
the misdeclaration of printf()?

The latter. It's trivial to fix by defining restrict as an empty macro
if the compiler doesn't claim C99 conformance and using the proper C99
prototype for printf.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <iu********************************@4ax.com> Ravi <[e-mail]> writes:

On Tue, 23 Sep 2003 23:16:10 +0530, Ravi <[e-mail]> wrote:

On 23 Sep 2003 17:34:22 GMT, Da*****@cern.ch (Dan Pop) wrote:

Do yourself a favour and learn how to obtain the preprocessor's output:
it's much easier to solve preprocessing issues this way than by
examining compiler error messages.
How would I do that on Turbo C++?

Back when I used it, some 13 years ago, it came with a separate utility
that was performing only the preprocessing. It was meant to help
in such cases.
Or you can also tell me how it can be done on a Linux machine with all
standard development tools installed.

Ever considered reading the gcc man page?

-E Stop after the preprocessing stage; do not run the
compiler proper. The output is preprocessed source
code, which is sent to the standard output.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Peter Shaggy Haywood]

Groovy hepcat Steve Zimmerman was jivin' on Mon, 22 Sep 2003 19:57:54
GMT in comp.lang.c.
Re: Your opinion's a cool scene! Dig it!

Ravi wrote:

> #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?
>
> Do you think this question aim's at analising a person's C skills?
> (It was asked in a Technical skill paper)
Thank you for this post, Ravi.

Output: 5 6.000000 0 0.000000
(There is one space before the 5.)

I don't know if it's implementation dependent.

If you don't know, why say anithing?
The code that you cite from the technical skill paper is referred to
as "spaghetti code" by _The New Hacker's Dictionary_. Spaghetti code
is code with an unnecessarily complex and tangled control structure.

Nonsense! This program has a very short and absolutely linear flow,
one statement after another - literally.

[Peter Nilsson]

"Ben Pfaff" <bl*@cs.stanford.edu> wrote in message
news:87************@pfaff.stanford.edu...

Ravi <[e-mail]> writes:

#define A B
#define B A

Pointless and stupid and effectively a no-op besides.

main()

You should declare main() as explicitly returning `int'. This is
required in C99. You should also write `void' within the
parentheses to give it a prototype, though it is not required.

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

You should return a value from main().

}

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

It is undefined for at least two reasons: first, trying to print
out an `int' using %f; second, for failing to write a final
new-line character to stdout.

The last omission merely invokes implementation defined behaviour.

[The standard means to say that in order to be a line, an implementation may
require the presense of a trailing \n, otherwise it will be ignored.
Unfortunately, C99 has a much worse situation of UB in the guise of IDB,
namely in the potential signal raised in conversions to signed integers.]

Do you think this question aim's at analising a person's C skills? ^^^^^^^^^
Quite probably!
(It was asked in a Technical skill paper)

I think it aims at testing something, but it has little to do
with C skills, especially considering the stupid macro
definitions. It tests knowledge of C trivia, not knowledge of C
usage.

I'd be asking if it was a typical example of the companies code... ;)

--
Peter

[Dan Pop]

In <3f******@news.rivernet.com.au> "Peter Nilsson" <ai***@acay.com.au> writes:

Ravi <[e-mail]> writes:

> Do you think this question aim's at analising a person's C skills?

^^^^^^^^^
Quite probably!

Few non-native English speakers are likely to get this one.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Joona I Palaste]

Dan Pop <Da*****@cern.ch> scribbled the following:

In <3f******@news.rivernet.com.au> "Peter Nilsson" <ai***@acay.com.au> writes:

Ravi <[e-mail]> writes:
> Do you think this question aim's at analising a person's C skills? ^^^^^^^^^
Quite probably!

Few non-native English speakers are likely to get this one.

I got it and I'm a non-native English speaker. What do I win?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"A friend of mine is into Voodoo Acupuncture. You don't have to go into her
office. You'll just be walking down the street and... ohh, that's much better!"
- Stephen Wright

[Barry Schwarz]

On 6 Oct 2003 17:02:25 GMT, Joona I Palaste <pa*****@cc.helsinki.fi>
wrote:

Dan Pop <Da*****@cern.ch> scribbled the following:

In <3f******@news.rivernet.com.au> "Peter Nilsson" <ai***@acay.com.au> writes:

Ravi <[e-mail]> writes:
> Do you think this question aim's at analising a person's C skills?
^^^^^^^^^
Quite probably!

Few non-native English speakers are likely to get this one.

I got it and I'm a non-native English speaker. What do I win?

Obviously you get to be declared (or is it defined) one of the few.
And if you watch American TV commercials that makes you one of the
brave and proud.
<<Remove the del for email>>