PRINTF()

[jt]

the statement

printf("%d %d");

will print the 1st 2nd initialized variables(if present)
how is tht possible

 

[Martin Ambuhl]

the statement

printf("%d %d");

will print the 1st 2nd initialized variables(if present)

What makes you think so? Just because your implementation doesn't barf
at broken code doesn't mean whatever random thing it produces is right.

how is tht possible

Neither that not 'tht' are in any way guaranteed. Learn to write legal
C; it will help you much more than your playing with broken code.

 

[Vladimir Oka]

the statement

printf("%d %d");

will print the 1st 2nd initialized variables(if present)
how is tht possible

No, it won't.

It will print whatever rubbish happens to be found by printf on
the stack where it expects two ints. Your implementation may
just happen to keep two previously initialised variables there.
Mine has proper rubbish.

Some would also argue it won't necessarily print a thing, as you
don't show you printed a terminating newline anywhere.

It's undefined what happens really, as you should have supplied
two ints.

 

[CBFalconer]

No, it won't.

It will print whatever rubbish happens to be found by printf on
the stack where it expects two ints. Your implementation may
just happen to keep two previously initialised variables there.
Mine has proper rubbish.

What stack? It has undefined behaviour.

 

[Vladimir Oka]

What stack? It has undefined behaviour.

Was that a necessary comment?

I even said it was undefined -- in the bit that you snipped.

And the reason OP was getting the behaviour he was had to do
with his particular implementation so that was the reply he got,
seeing as this was what he was talking about. His question was
"how is that possible". I gave one possible theory.

I know you've all been busy with Jacob and stack recently but I
wasn't expecting it to spill over all of the group...

 

[Richard]

What stack? It has undefined behaviour.

Probably the stack that his environment uses I would dare say. The one
the debugger displays. Duh. Whether that stack is used in this case is
another issue, but it was fairly clear what stack he meant.

 

[Peter Nilsson]

Actually, it expects two void pointers.

Was that a necessary comment?

Was yours?

Martin gave the answer the OP needed.

 

[jaysome]

Actually, it expects two void pointers.

I thought the "%d" conversion specifier expects type int. Isn't the
conversion specifier for a void pointer "%p"?

The way I read your comment, you are you saying that something like this
is acceptable?

printf("%d %d", (void*)98, (void*)99);

Isn't that undefined behavior?

 

[Micah Cowan]

I thought the "%d" conversion specifier expects type int. Isn't the
conversion specifier for a void pointer "%p"?

Yes. I believe it's fair to say that Mr Nilsson misread.

 

[Vladimir Oka]

Was yours?

Martin gave the answer the OP needed.

I respectfully disagree.

The OP asked along the lines of "how is it possible that I get
this silly behaviour". I disagree it enhances OP's understanding
of software in general if he gets the answer "it's undefined
behaviour, don't do it (and don't think about it further)." My
reply offered one possible scenario that could lead to undefined
behaviour having the outcome seen by the OP. I believe that is
the reply OP needed.

Not to mention I also pointed out it was undefined, but that was
snipped from CBFalconer's response, making my reply seem incomplete.

 

[Richard Heathfield]

Vladimir Oka said:

Not to mention I also pointed out it was undefined, but that was
snipped from CBFalconer's response, making my reply seem incomplete.

Your reply remains intact. It can be found here:

<[email protected]>

Chuck's response was correct (albeit not as helpful as it might have been)
insofar as its intent was to point out that the C language doesn't mandate
or require implementations to use a stack in the sense that your reply
suggested.

I suspect (but of course cannot be certain) that he may not have read all
the way to the bottom of your reply - I would imagine that he just got as
far as the word "stack" and snapped off a reply based on what he had read
up to that point. In any case, it is /his/ response that is incomplete.

Complete responses are, of course, impossible in the general sense. There
is a tendency for the regular contributors of comp.lang.c to expect every
reply to mention every relevant nuance of the language, and this simply
isn't possible (or even necessarily desirable).

 

[Kenny McCormack]

I respectfully disagree.

The OP asked along the lines of "how is it possible that I get
this silly behaviour". I disagree it enhances OP's understanding
of software in general if he gets the answer "it's undefined
behaviour, don't do it (and don't think about it further)." My
reply offered one possible scenario that could lead to undefined
behaviour having the outcome seen by the OP. I believe that is
the reply OP needed.

Not to mention I also pointed out it was undefined, but that was
snipped from CBFalconer's response, making my reply seem incomplete.

Welcome to CLC.

I think I need to add this to my list of useful CLC-related links:

http://redwing.hutman.net/~mreed/warriorshtm/

I'll leave it some of my anti-Clique colleagues to detail which one of
them is the most emblematic of CLC.

 

[Vladimir Oka]

>
Welcome to CLC.

Oh, I've been here before. Sort of a regular for a while, too.

And, I do remember everyone -- including you.

 

[Kenny McCormack]

Oh, I've been here before. Sort of a regular for a while, too.

And, I do remember everyone -- including you.

Be that as it may, you may have missed the thread in which we've been
discussing the above URL's collection of character profiles. I think it
would behoove you to check it out.

P.S. They say I'm a "Target" - I'm not sure if I am completely comfortable
with that designation, but parts of it are certainly "on target"

 

[Richard]

Be that as it may, you may have missed the thread in which we've been
discussing the above URL's collection of character profiles. I think it
would behoove you to check it out.

P.S. They say I'm a "Target" - I'm not sure if I am completely comfortable
with that designation, but parts of it are certainly "on target"

You are most certainly not a Target. And being called one is reminiscent
of a Godfather, his sycophants and henchmen turning on you.

 

[santosh]

Be that as it may, you may have missed the thread in which we've been
discussing the above URL's collection of character profiles. I think
it would behoove you to check it out.

P.S. They say I'm a "Target" - I'm not sure if I am completely
comfortable with that designation, but parts of it are certainly "on
target"

You are most certainly not a Target. [ ... ]

Indeed. If only he were merely a Target.

 

[Peter Nilsson]

Yes. I believe it's fair to say that Mr Nilsson misread.

Indeed. Many apologies. Thanks to jaysome for picking it up.

 

[Peter Nilsson]

I respectfully disagree.

The OP asked along the lines of "how is it possible
that I get this silly behaviour".

The OP gave every indication they thought the behaviour
was legitimate. Your reply could only reinforced such a
belief.

I disagree it enhances OP's understanding of software
in general if he gets the answer "it's undefined
behaviour, don't do it (and don't think about it
further)."

That's a poor summary of:

What makes you think so? Just because your implementation
doesn't barf at broken code doesn't mean whatever random
thing it produces is right. ... Neither [is that] in any
way guaranteed. Learn to write legal C; it will help you
much more than your playing with broken code.

Martin challanged the OP to question and try to justify
their assumption. He pointed out that it was wrong. And he
then advised that their time would be better spent in more
constructive programming using correct techniques.

My reply offered one possible scenario that could lead
to undefined behaviour having the outcome seen by the
OP. I believe that is the reply OP needed.

Not to mention I also pointed out it was undefined, but
that was snipped from CBFalconer's response, making my
reply seem incomplete.

Just after I handed the minor a six pack I did say they
probably shouldn't be doing this.

 

[Vladimir Oka]

The OP gave every indication they thought the behaviour
was legitimate. Your reply could only reinforced such a
belief.

I didn't read it that way. Quite the opposite, in fact. I felt
OP said something along the lines of "how is this strange [and
obviously wrong] behaviour possible". But, given the OP's
writing skills this is obviously open to (our) interpretation.

I disagree it enhances OP's understanding of software
in general if he gets the answer "it's undefined
behaviour, don't do it (and don't think about it
further)."

That's a poor summary of:

What makes you think so? Just because your implementation
doesn't barf at broken code doesn't mean whatever random
thing it produces is right. ... Neither [is that] in any
way guaranteed. Learn to write legal C; it will help you
much more than your playing with broken code.

Martin challanged the OP to question and try to justify
their assumption. He pointed out that it was wrong. And he
then advised that their time would be better spent in more
constructive programming using correct techniques.

Martin's reply could have been interpreted as dismissive --
which is too in the eye of the beholder. What he could but
didn't choose to do was point at the correct thing expected in
the OP's code.

What I disagreed with was this approach, i.e. perceived (by me)
incompleteness of Martin's reply.

Just after I handed the minor a six pack I did say they
probably shouldn't be doing this.

Again, I fail to see how my reply could have possibly encouraged
OP to continue using the construct or indeed make him believe
it's correct. Winky smiley notwithstanding.

I won't belabour this any more.

 

[Nick Keighley]

Kenny McCormack wrote:

Oh, I've been here before. Sort of a regular for a while, too.

And, I do remember everyone -- including you.

Kenny McCormack is a troll who mostly posts just to get a response.
It is best to ignore him.