Strange Behaviour of this function

C

Chris Dollin

raghu said:
But it happened in gcc compiler. I modified the code for number of
times and concluded in that manner.

So? /The behaviour is undefined/. An implementation can do what it
likes. "What it likes" is often whatever the natural consequence of
the implementation's choices are - ie, it doesn't check, it doesn't
care.

There's no point in just tinkering with a compiler and seeing
what happens. A different compiler could make different choices.

What's /likely/ to have happened is that `printf` returns a result
in some integer register, let's call it R0. The call to `b` doesn't
do anything (well, it might push and pull a return address), so
doesn't alter R0. Then when `b` returns, the value of R0 is assigned
to `x`.

A decent compiler will of course have warned about the implicit
int definition of `b` and that it doesn't have a `return` statement.

If you insist on tinkering with code, try adding:

int fiddleResult() { return 17; }
int b() { fiddleResult(); }
... main as before ...

I expect you'll now find that `x` gets `17` as its value.
 
R

Richard Tobin

Chris Dollin said:
There's no point in just tinkering with a compiler and seeing
what happens. A different compiler could make different choices.

Or the next version of the same compiler. Or the same compiler on a
different system. Or even the same compiler with different
optimisation flags. Or the same compiler on the same system, after
you installed a patch to the system libraries.

-- Richard
 
C

Chris Dollin

Richard said:
Or the next version of the same compiler. Or the same compiler on a
different system. Or even the same compiler with different
optimisation flags. Or the same compiler on the same system, after
you installed a patch to the system libraries.

Or the same compiler on the same system with the same libraries,
at a different time or on a file with a different name or when
run by a different user or in a different directory or with
a different Prime Minister or in the rain or when eating a lettuce-
and-tomato sandwich.

(You never know when your webcam is on, or what processes are doing
with the data ...)

PS Yes, Richard T is right.
 
D

Dave Thompson

I do not think so. The prefix means that the block after the prefixes
(on multiple lines) is what the original writer wrote, but possibly

I agree with this principle, but I (mostly) agree with Keith that for
C (or other program) source, layout is (often) significant and
shouldn't be changed without at least indicating it.

And if quoting and snipping results in signficant context change, such
as losing referents of pronouns, I consider it not only acceptable but
highly preferable to edit just enough to restore the original
_meaning_, marked usually in scholarly style with square brackets.
reformatted. And it does not matter whether the original was C code
or English text, as long as the quote does mean exactly the same as
the original. Darn, I even modify quoted-printable text coded from
ISO-8859-1 to the plain ISO-8859-1 text.
At least according to the standards, QP is a _transfer_ encoding; it
is supposed to be applied to what the sender writes _after_ they
approve it, and removed _before_ it is shown to the reader. If you
need to fix it, and because of bogus agents, servers, or gateways
sometimes you do, you are _restoring_ the original intent not changing
it. Fixing stray URL-encoding or MIME-headering or broken UTF are to
me in the same category, although the last is tedious enough I don't
bother unless it's vital to the subject(s) I want to respond to.

- David.Thompson1 at worldnet.att.net
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,481
Members
44,900
Latest member
Nell636132

Latest Threads

Top