Re: Strange behaviour of printf. See the code below and please tell why it behaves in this way.
- From: Keith Thompson <kst-u@xxxxxxx>
- Date: Thu, 19 May 2005 20:36:53 GMT
SM Ryan <wyrmwif@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
> "Peter Nilsson" <airia@xxxxxxxxxxx> wrote:
> > SM Ryan wrote:
> > > "Emmanuel Delahaye" <emdel@xxxxxxxxxxxxxx> wrote:
> > >
> > > > No. The behaviour is undefined. Period.
> > >
> > > How wonderfully unhelpful.
> > > Actually anti-helpful.
> > >
> > > A question was asked on an observed behaviour, so the behaviour was
> > > defined on that implementation.
> >
> > No, the only thing you can say was that behaviour was _observed_.
>
> No it was defined in that implementation. Once you have some real
> world experience, you will discover argument list and argument
> passing are always meticulously well defined in each
> implementation. This allows linkages between the code of one
> compiler and another--an important real world consideration. Often
> the argument passing is not even left up the compiler: the CPU
> designer defines external linkage protocols and all compilers for
> that CPU. Internal linkages, in C that would mean calling a static
> function, can follow alternate protocols but often don't except for
> optimising compilers.
[ Obnoxious '#' quoting character changed to '>'. ]
[ Obnoxious long lines re-wrapped. ]
(Context: the code in question passed a struct { int i; int j; } to
printf with a format string specifying two int arguments; it happened
to print the i and j members of the struct.)
First, what we discuss here is standard C. We recognize that
implementations have system-specific characteristics, but if we're
going to discuss non-portable code we will *at least* point out that
it's non-portable, and why it's non-portable. The code in question
invokes undefined behavior, and will almost certainly break on some
implementations. The task the code was trying to accomplish could
easily be achieved portably; even if it's a hack rather than a bug,
there's no advantage in using it. It's also an extremely fragile
technique. It might work for printf() but fail for a function that
doesn't take a fixed number of arguments, or, as you point out, it
might work for an external function but fail for a static function.
Imagine a program's behavior changing subtly because you add a
"static" keyword to a function definition. Imagine tracking down the
bug, assuming you even notice it. Now imagine avoiding such bugs by
writing portable code in the first place.
Second, "defined" means "documented". If you can cite the
system-specific documentation that states, or implies, that the code
is guaranteed to behave in the observed manner you *might* have a
point. The OP was using VC++. Was your statement based on the actual
VC++ documentation, or were you guessing? I can't tell, because you
didn't provide any hints as to *why* the OP's code was equivalent to
printf("i==%d i==%d \n",var.i,var.j,var.i);
You could have mentioned that excess arguments to printf() are ignored
(the standard actually specifies that). But most importantly, if you
intended to provide information that's specific to VC++, you should
have said so. This is comp.lang.c; unqualified statements made here
are assumed to refer to the standard language. In that context, your
answer was simply wrong. This isn't even about redirecting the
discussion to a system-specific newsgroup; it's about making
statements that are misleading in the context of this one.
Just providing a literal answer to a poster's question is often not
helpful, as you've demonstrated. Your answer may (or may not) be
correct within the narrow confines of the OP's particular
implementation, but it could easily lead the OP to believe things that
simply aren't true. And now you're annoyed at the rest of us for
providing useful information rather than just providing a "correct"
but misleading answer to the question.
--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
.
- Follow-Ups:
- References:
- Prev by Date: Re: how to creat a web browser
- Next by Date: Good C Compiler for Windows..
- Previous by thread: Re: Strange behaviour of printf. See the code below and please tell why it behaves in this way.
- Next by thread: Re: Strange behaviour of printf. See the code below and please tell why it behaves in this way.
- Index(es):
Relevant Pages
|
