Help me

[Nikhil Bokare]

I HAVE TWO QUESTIONS:

1.WHY DON'T WE NEED TO INCLUDE STDIO.H IN C PROGRAMS?

2.WHAT IS PRINTED WHEN WE EXECUTE THE FOLLOWING PROGRAM:

main()
{
printf("%d %d %d %d");
}

This program actually prints the same value every time you run the
program on a given machine.
What are those values?

[santosh]

Nikhil Bokare wrote:

I HAVE TWO QUESTIONS:

All uppercase text is considered rude.

1.WHY DON'T WE NEED TO INCLUDE STDIO.H IN C PROGRAMS?

Because STDIO.H doesn't exist in Standard C. OTOH, stdio.h does,and
it's included in most programs because I/O is a common requirement for
any non-trivial program.

2.WHAT IS PRINTED WHEN WE EXECUTE THE FOLLOWING PROGRAM:

main()
{
printf("%d %d %d %d");
}

It invokes undefined behaviour, so that anything can happen. It might,
on the next run, trash all your music files.

This program actually prints the same value every time you run the
program on a given machine.
What are those values?

The output is irrelevant.

[user923005]

On Mar 8, 9:50 am, "Nikhil Bokare" <[e-mail]:

I HAVE TWO QUESTIONS:

1.WHY DON'T WE NEED TO INCLUDE STDIO.H IN C PROGRAMS?

2.WHAT IS PRINTED WHEN WE EXECUTE THE FOLLOWING PROGRAM:

main()
{
printf("%d %d %d %d");

}

This program actually prints the same value every time you run the
program on a given machine.
What are those values?

Time to invest in a good C book.
I suggest K&R2. If you can't afford it, get a copy from your local
library.

[Christopher Benson-Manica]

Nikhil Bokare <nb*****@gmail.comwrote:

I HAVE TWO QUESTIONS:

QUIET DOWN. There's no need to shout here.

2.WHAT IS PRINTED WHEN WE EXECUTE THE FOLLOWING PROGRAM:

"We" aren't executing anything, and apparently neither are you, or you
wouldn't be asking.

main()
{
printf("%d %d %d %d");
}

This program actually prints the same value every time you run the
program on a given machine.

That so? Sounds like you need to find yourself a new instructor.

What are those values?

Well *I* ran the program and it launched nuclear missiles at Moscow,
but I run a DeathStation 9000 and I'm used to such quirks when I run
poorly written C programs.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Beej Jorgensen]

Nikhil Bokare <nb*****@gmail.comwrote:

>main()
{
printf("%d %d %d %d");
}

printf() is going to start looking for parameters that correspond to the
%ds, but there are no more, so the actual results could be anything.

>This program actually prints the same value every time you run the
program on a given machine.

For me, it prints different values every time I run it on my machine:

0 -1077652376 134513659 -1208979460
0 -1074653368 134513659 -1208328196
0 -1079993800 134513659 -1208889348
0 -1074364536 134513659 -1208938500

But neither your program's behavior nor my program's behavior should be
entirely surprising, by C99 7.15.1.1p2, "The va_arg macro":

# If there is no actual next argument [...] the behavior is undefined

Anything could have happened on that call to printf(), really.

>What are those values?

Just garbage, presumably whatever was on your stack from before the
call. (But even that depends on the implementation. If you want to get
fun, compile to assembly language and see exactly what it's doing. Um,
but don't post that here. :)

-Beej

[Kenneth Brody]

Christopher Benson-Manica wrote:

>
Nikhil Bokare <nb*****@gmail.comwrote:

[...]

main()
{
printf("%d %d %d %d");
}

This program actually prints the same value every time you run the
program on a given machine.

That so? Sounds like you need to find yourself a new instructor.

What are those values?

Well *I* ran the program and it launched nuclear missiles at Moscow,
but I run a DeathStation 9000 and I'm used to such quirks when I run
poorly written C programs.

Fortunately, you can run the following on the DS-6000 to cause the
missiles to self-destruct before they arrive at their target:

void main(void) { int i = i++; }

Unfortunately, running that on your DS-9000 will cause the self-
destruct to be disabled.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Peter Nilsson]

Beej Jorgensen <[e-mail]:

Nikhil Bokare <[e-mail]:

main()
{
printf("%d %d %d %d");
}

printf() is going to start looking for parameters that correspond
to the %ds, but there are no more, so the actual results could be
anything.

Even if there were arguments, the lack of prototype for printf
means there's no guarantee that it would find them (or even that
printf itself is found!)

<snip>

>
But neither your program's behavior nor my program's behavior
should be entirely surprising, by C99 7.15.1.1p2, "The va_arg
macro":

# If there is no actual next argument [...] the behavior is
undefined

Although it's not an unreasonable assumption, the standard
doesn't actually require printf (et al) to use the va_ macros.
The behaviour is still undefined though because the fprintf
specifications specifically require an int argument to supplied
when the %d conversion specifier is used.

Anything could have happened on that call to printf(), really.

What are those values?

Just garbage, presumably whatever was on your stack from before
the call. (But even that depends on the implementation. If you
want to get fun, compile to assembly language and see exactly
what it's doing.

That's probably what the OP did, and probably why they stated
that all implementations will behave in a certain way. Looking
at assembly to learn C or C behaviour, even for broken programs,
is really is the worst thing you can encourage a newbie to do.
It's just too easy to develop misguided assumptions.

Unfortunately, human nature will make newbies do it anyway.

--
Peter

[Beej Jorgensen]

Peter Nilsson <ai***@acay.com.auwrote:

>Looking at assembly to learn C or C behaviour, even for broken
programs, is really is the worst thing you can encourage a newbie to
do.

Bah. I can think of worse. :)

I agree that trying to learn C behavior from the resulting assembly is a
bad idea in general. I mean, think of how much implementation-defined
behavior is in there! They need to know that the assembly result is
merely one compiler's interpretation of C, and not at all canon.

However, I still think looking at the assembly results of a C program is
a good thing in general. One can learn a lot about systems and
compilers. If he wants to know where that garbage output comes from, no
amount of standard C will answer that question.

Maybe I read him wrong, but my take on this guy was that he wasn't just
flailing at random, but was pushing the limits to see into the black
box.

Besides, if he's going to look in there anyway, might as well offer a
small amount of direction.

-Beej

[santosh]

Beej Jorgensen wrote:

Peter Nilsson <ai***@acay.com.auwrote:

Looking at assembly to learn C or C behaviour, even for broken
programs, is really is the worst thing you can encourage a newbie to
do.

<snip>

Maybe I read him wrong, but my take on this guy was that he wasn't just
flailing at random, but was pushing the limits to see into the black
box.

You're being sarcastic aren't you?

It looked like some sort of trick question, albeit a very poor one.

[Randy Howard]

On Thu, 8 Mar 2007 11:50:11 -0500, Nikhil Bokare wrote
(in article <11*********************@v33g2000cwv.googlegroups. com>):

I HAVE TWO QUESTIONS:

I have one more, did you compose the first half of this on a Commodore
64?

1.WHY DON'T WE NEED TO INCLUDE STDIO.H IN C PROGRAMS?

That depends, for some programs, your question is a trick question, and
for those that you don't need it, the answer is obvious, because you
don't need it. Example: A program (or at least a compilation unit)
where you use none of the things provided which require stdio.h.

2.WHAT IS PRINTED WHEN WE EXECUTE THE FOLLOWING PROGRAM:

main()
{
printf("%d %d %d %d");
}

It depends. It would be nice if the implementation said:

Stupid programmer detected: fire him immediately.

Alas, I doubt it will.

This program actually prints the same value every time you run the
program on a given machine.

For you, maybe.

What are those values?

Why should we guess what happens on your computer?


--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw