increment evaluation

[pradeeparc]

hii,
plz help to knw how this prg wrk in detail
#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);
printf("%d%d",a,b);
}

[Richard Heathfield]

pr********@gmail.com said:

hii,
plz help to knw how this prg wrk in detail

It doesn't.

#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);

See the FAQ: http://c-faq.com/cpp/safemacros.html

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[user923005]

On Oct 12, 12:03 am, [e-mail] wrote:

hii,
plz help to knw how this prg wrk in detail

#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);
printf("%d%d",a,b);
}

That is an example of undefined behavior (for several reasons).
You have a varadic function (printf) with no protype in scope.
You have a function macro which is given an argument used more than
once which is incremented causing several updates with no intervening
sequence point.

Probably, you want something like this:

#include <stdio.h>

static long CUBE (const long x)
{
printf("%d * %d * %d ", x, x, x);
return (x * x * x);
}

int main (void)
{
long a;
int b = 3;
a = CUBE(b++);
printf (" = %ld\n", a);

a = CUBE(b);
printf (" = %ld\n", a);

return 0;
}

[Martien Verbruggen]

On Fri, 12 Oct 2007 00:03:17 -0700,
pr********@gmail.com <pr********@gmail.comwrote:

hii,
plz help to knw how this prg wrk in detail

Please, in the future, make an attempt to spell correctly. The little
bit of effort you save in typing, if any, means all your readers have to
work a little bit harder to parse your message. It doesn't look cool
either. It looks silly.

#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);
printf("%d%d",a,b);
}

This program invokes undefined behaviour, for several reasons. Please
see the C FAQ at c-faq.com, for example, and read questions 3.2, 10.1,
11.35, 15.21, and then read the whole thing. It's really worth the time.

Martien
--
|
Martien Verbruggen |
| In a world without fences, who needs Gates?
|

[Joachim Schmitz]

<pr********@gmail.comschrieb im Newsbeitrag
news:11**********************@v23g2000prn.googlegr oups.com...

hii,
plz help to knw how this prg wrk in detail

This style of writing isn't received well here... this is a news group and
not a chat room

#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);
printf("%d%d",a,b);
}

It invokes Undefined Behavoir because
a) you don't provide a prototype for a varadic funtion, printf() e.g. by
#include <stdio.h>
b) the output you intend to generate doesn't end with a linefeed ('\n'), so
your program may or may not produce any output
c) the macro CUBE has side effects that modify an operator several times
without a sequence point.

I guess your real question is about the macro CUBE
That macro is expanded by the preprocesser, so your compiler actually sees:

a=(b++*b++*b++);

When b gets incremented is up to the implementation as long as it happens
before the next sequence point.
On implementation I tried this on came up with "606" (i.e a=60 or 3*4*5 and
b=6), another with "276" (i.e. a=27 or 3*3*3 and b=6) and both are right.

Also you shouldn't use main() but rather int main(void) and also end it with
a return 0; (or EXIT_SUCCESS or EXIT_FAILURE from <stdlib.h>)

Bye, Jojo

[Chris Dollin]

pr********@gmail.com wrote:

hii,
plz help to knw how this prg wrk in detail

#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);
printf("%d%d",a,b);
}

Tht prg ds nt wrk t ll; t hs t lst tw xmpls f "ndfnd bhvr". Y ddn't #ncld
<std.hs th cll t prntf sn't dfnd. ls, th xprssn `CUB(b++)` xpnds t
`b++ * b++ * b++`, whch vlts /rqrmnt/ tht n xprssn wrts t mst nc t
vrbl btn sqnc pnts; fr dtls s th FQ.

--
Chrs "aooeooaaiaalepeae ..." Dlln

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

[Philip Potter]

pr********@gmail.com wrote:

hii,
plz help to knw how this prg wrk in detail
#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);
printf("%d%d",a,b);
}

Others have said that this program causes undefined behaviour. What does
this mean? It means Bad Things.

The C programming language is defined by a set of standards published by
ISO. The main ones are C89 (the first one), and C99 (the most recent).
The standard describes what a valid C compiler (or to use the Standard's
language, "implementation") must do. In certain places, the standard
gives the implementation a range of options - e.g. int can be any size,
as long as it's 16 bits or more.

For a program which causes undefined behaviour (UB), the standard places
no restrictions on the implementation. This means that the
implementation can do *anything it likes* when it encounters UB. What
this means is that a compiler which is in every way a working and
correct C compiler can fail to compile your code - or worse, compile
your code into something with bugs in it. Given there are hundreds (if
not thousands) of C implementations out there, this is a Bad Thing.

Of course, you may find that *your* compiler works exactly as you expect
it to. This is allowed by the Standard, because it places no
restrictions on the compiler. But one of the reasons for writing in C is
that there are many different C compilers on many different types of
computer, and if you do not invoke UB then the Standard guarantees your
program will work on *all* of these compilers without needing a rewrite.
This is called "portability". If you rely on quirks of your own
compiler, it may not compile on any other.

Why would you want to write code that will compile on any C compiler?
Well, it might be nice if you could give (or sell!) your nice Windows
program to Linux users at no extra cost to yourself. Another reason is
that if you write C code that works on lots of C compilers, then users
of all those compilers will know what you mean and will be able to help.
If you write C code which only works on your compiler, then you cut
yourself off from that expertise, because users of other compilers are
not familiar with the quirks of your compiler.

There are sometimes good reasons for writing code for which the Standard
does not define correct behaviour. This includes using system-specific
features such as graphics, networks, when standard C code to achieve
what you want doesn't exist. However in this situation standard C code
to do what you want *does* exist, so you should write standard C.

--
Philip Potter pgp <atdoc.ic.ac.uk

[Richard]

Martin Ambuhl <ma*****@earthlink.netwrites:

pr********@gmail.com wrote:

>hii,
plz help to knw how this prg wrk in detail

Given that you are so sloppy with your writing that "hii", "plz",
"knw", "prg", and "wrk" are all childish gibberish, it is unlikely
that you have enough respect for a language to ever be a competent
programmer.

Of course, your program doesn't work at all, so it makes no sense to
explain in detail how it works. It has undefined behavior.

What IS wrong with you people? You *know* others have already pointed
this out.

[karthikbalaguru]

On Oct 12, 12:03 pm, [e-mail] wrote:

hii,
plz help to knw how this prg wrk in detail

#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);
printf("%d%d",a,b);

}- Hide quoted text -

- Show quoted text -

Be alert - Some books have solutions for this and it is a
famous question in few C tests. But , in reality this cannot
have a defined solution.

Ans - Undefined Behaviour.

The Macro CUBE has side effects that modify an operator several times
without a sequence point.

Refer C-Faq and Kernighan & Ritchie books for the correct
answer.

Karthik Balaguru

[Chris Dollin]

karthikbalaguru wrote:

On Oct 12, 12:03 pm, [e-mail] wrote:

>hii,
plz help to knw how this prg wrk in detail

#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);
printf("%d%d",a,b);

Be alert - Some books have solutions for this and it is a
famous question in few C tests. But , in reality this cannot
have a defined solution.

Ans - Undefined Behaviour.

The Macro CUBE has side effects that modify an operator

variable.

several times without a sequence point.

Refer C-Faq and Kernighan & Ritchie books for the correct
answer.

--
Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[Mark L Pappin]

Chris Dollin <ch**********@hp.comwrites:

karthikbalaguru wrote:

>On Oct 12, 12:03 pm, [e-mail] wrote:

>>#define CUBE(x) (x*x*x)
a=CUBE(b++);

>The Macro CUBE has side effects that modify an operator

variable.

>several times without a sequence point.

The macro 'CUBE()' has no side effects.
The expression 'b++' has a side effect.

Using an expression with a side effect as an argument to a macro is a
Bad Idea if that macro evaluates that argument more than once.

The macro 'CUBE()' evaluates its argument more than once.

mlp

[Charlie Gordon]

"Mark L Pappin" <ml*@acm.orga écrit dans le message de news:
m3************@Claudio.Messina...

Chris Dollin <ch**********@hp.comwrites:

>karthikbalaguru wrote:

>>On Oct 12, 12:03 pm, [e-mail] wrote:

>>>#define CUBE(x) (x*x*x)
a=CUBE(b++);

>>The Macro CUBE has side effects that modify an operator

variable.

>>several times without a sequence point.

The macro 'CUBE()' has no side effects.
The expression 'b++' has a side effect.

Using an expression with a side effect as an argument to a macro is a
Bad Idea if that macro evaluates that argument more than once.

The macro 'CUBE()' evaluates its argument more than once.

Technically, the macro does not "evaluate" its arguments, it just expands to
a sequence of tokens that may be part of an expression where multiple
occurrences of a side effect invokes undefined behaviour.

int a = CUBE(b++); // invokes undefined behaviour;
size_t size = sizeof(CUBE(b++)); // far fetched, but OK.

Even the fact that the same argument be present more than once in the macro
expansion is not necessarily an issue:

#define NP(x,y) ((y) 0) ? ((x) + 1) : ((x) - 1))

int a = NP(b++, 1); // side effect only evaluated once.

In the OPs macro, we have more than one misunderstanding on how macros
operate: the macro argument is expanded 3 times in such a way as to cause
undefined behaviour for most side effects *and* it is not properly
parenthesized in the expansion, causing it to not evaluate as expected:

CUBE(a+1) -a+1*a+1*a+1 -3 * a + 1

You can fix this by always surrounding macro arguments with pairs of
parentheses in the definition:

#define CUBE(x) ((x)*(x)*(x))

but is will not prevent the issue related to side effects.

Macros are *very* difficult to master, newbies should avoid them. The OP
can accomplish the same effect safely and correctly with an inline function:

static inline int cube(int x) { return x * x * x; }

--
Chqrlie.

[user923005]

On Oct 14, 11:33 pm, "Charlie Gordon" <[e-mail]:
[snip]

Macros are *very* difficult to master, newbies should avoid them. The OP
can accomplish the same effect safely and correctly with an inline function:

static inline int cube(int x) { return x * x * x; }

Note:
'inline' keyword requires C99

There are several C90 compilers that support it as an extension, but
it is not required by the langauge.

Probably, you already know that but I am not sure if the OP does.

[Charlie Gordon]

"user923005" <dc*****@connx.coma écrit dans le message de news:
11**********************@t8g2000prg.googlegroups.c om...

On Oct 14, 11:33 pm, "Charlie Gordon" <[e-mail]:
[snip]

>Macros are *very* difficult to master, newbies should avoid them. The OP
can accomplish the same effect safely and correctly with an inline
function:

static inline int cube(int x) { return x * x * x; }

Note:
'inline' keyword requires C99

There are several C90 compilers that support it as an extension, but
it is not required by the langauge.

Probably, you already know that but I am not sure if the OP does.

The OP should understand that it is easier to find a compiler that supports
inline functions for any desktop PC than to master the art of C macros ;-)

--
Chqrlie.