Question about the *= (and similar) operator

[Andrew Poelstra]

I understand the question and I understand straightforward answers to
the question. I have written a fair amount of above basic programmes
in C therefore it has been possible for me to become more than a basic
user of the language without knowing the answer to the question.


Since you're claiming that it would answer my question can you explain
what
series of arguments starting from the result of the experiment and I
don't know
which other premises would lead me to conclude that the behaviour I
observed
was standard as opposed to implementation defined ?
Otherwise , Chris may know the answer to the question but he claimed
that the
experiment would offer me "far more insight". I don't know what this
substantial
amount of insight is supposed to be. I'm not even sure whether an
answer to my
question is supposed to be part of this insight.
The replies in the thread have offered me insight. The reply by Keith
above for
example or the quote form the standard or the comparison between macros
and
operators given in a different post (not quoted here). I wouldn't have
gotten any
of that from an experiment even if it would have answered my question
and I
don't believe it would have.

The standard quotations didn't help you, did they? As I type this people
are bickering over what they mean and whether they are relevant to your
question.

If you wanted the difference between functions and macros, you could have
posted that question.

He's a quick code sample for the experiment.

#include <stdio.h>

int main (void)
{
int r = 15;
r *= 3 + 5; /* r * 3 + 5 is 50, but r * (3 + 5) is 120. */

printf ("r is %d.\n", r); /* What does this output? */
return 0;
}

So you're saying that writing and running a small C programme would
teach me
about fishing. But I'm a city person you see , I don't fish. If I want
fish I just go
to the supermarket.

If you give a man a fish, he'll eat for a day. If you teach a man to fish,
he'll eat for a lifetime.

I'm saying that if I give you code, you'll have a program for a day,
but if you learn to code, you'll be able to program for life.

 

[Skarmander]

Two correct answers have already been offered:
(1) Compare precedence of " *= " with " + ".
(2) Write a test program and find out.

I'll offer a little "meta-discussion".

First, is it really conceivable that someone would invent a language
in which
a *= b+c
*really* becomes
a = (a*b) + c
?

If you really suspected this might be the case, then you either have
*very*
poor intuition about expression "design" or you've somehow concluded
that the C language was designed by a sadist, who's trying to trick you
with peculiar rules.

The "as-if" clause applies here: the language may behave *as if* this were
the case...

Is it really conceivable that someone would invent a language in which
a == b | c
*really* becomes
(a == b) | c
?

If you really suspected this might be the case, then you understand boolean
logic and bitwise operators in C...

S.

 

[Keith Thompson]

Frankly, postings in this newsgroup may be partly to blame for
creating the misconception that (any but rarish) C expressions are
ambiguous. For example, in another thread I introduced an
interesting issue, but added a peculiar formula, which relied on
function pointers all smelling the same, for humorous effect. The
interesting part of the post was ignored, but several responses,
while acknowledging that function pointers probably always smell the
same on all present implementations, focussed on the question of
whether this was spelled out in the Standard.

Actually, I thought the discussion about function pointers was quite
interesting.

(BTW, your articles tend to have a lot of variation in the lengths of
lines. If you could re-format your text, it would make it a lot
easier to read. I see you're using Google Groups; I don't know of a
good way to re-format your text in that interface, unless you
copy-and-paste it to a text editor, reformat it, and copy-and-paste it
back.)

 

[James Dow Allen]

Actually, I thought the discussion about function pointers was quite
interesting.

Yes, but I still think a discussion of gcc's peculiar optimization
re malloc() would be *more* interesting. And, frankly, I was
annoyed that some of the "interesting function pointer" discussion
focussed on the nit that an unseen argument declaration wasn't
specifically shown to be (size_t).

(BTW, your articles tend to have a lot of variation in the lengths of
lines.

Thanks for pointing this out. Google seems to change its
interface details frequently. For a while, or so I thought, Google
was sending my posts properly, just displaying them badly.
In future, I'll try to use much shorter lines (though Google will
eventually munge these if enough ">>>" are prefixed.

In the "Unix philosophy" (e.g. *vi*), line-feeds are generated
only when I press the line-feed button. I guess this is too
simple-minded in the post-literate era.

... I see you're using Google Groups;

I apologize, and I'm sure it costs me what little credibility
I might retain. Alternatives have been mentioned, but
I'm not sure they're appropriate *for the Internet cafe
environment*.

Keith Thompson (The_Other_Keith)

James Allen (The_One_with_Dow)

We must do something. This is something. Therefore, we must do this.

I guess we should record that as an "Aye" vote.
I'm still voting "Neigh."

 

[pete]

James Dow Allen wrote:

I guess we should record that as an "Aye" vote.
I'm still voting "Neigh."

You have a horse voice.

 

[CBFalconer]

You have a horse voice.

You lose, so pony up.

 

[Keith Thompson]

Yes, but I still think a discussion of gcc's peculiar optimization
re malloc() would be *more* interesting.

You made three points in your original article (subject "gcc knows
about malloc()"):

1. gcc assumes that malloc()'s return value is not an alias for
another pointer.

Compilers are allowed to use knowledge of functions in the standard
library. It's a reasonably cool optimization, but there's not all
that much more to say about it.

2. The usual statements in this newsgroup about the danger of casting
the result of malloc() rather than using "#include <stdlib.h>" are
misleading.

Sorry, you were wrong about that. The usual statements about this are
correct; some of your own statements were misleading. If you want to
re-discuss the details, please do so in the original thread, or start
a new one.

3. With a certain piece of code, gcc dies with a segmentation fault
during compilation.

And, frankly, I was
annoyed that some of the "interesting function pointer" discussion
focussed on the nit that an unseen argument declaration wasn't
specifically shown to be (size_t).

I don't know why you're annoyed. It was a valid point, and frankly
you don't get to decide what the rest of us find interesting. (Nuance
is difficult in plain text; that last sentence wasn't meant to be as
harsh as it probably sounded.)

 

[CBFalconer]

.... snip ...

You made three points in your original article (subject "gcc knows
about malloc()"):

1. gcc assumes that malloc()'s return value is not an alias for
another pointer.

Compilers are allowed to use knowledge of functions in the standard
library. It's a reasonably cool optimization, but there's not all
that much more to say about it.

Of course it can make that assumption. malloc, if successful,
always return a pointer to fresh storage. realloc may not, but any
copies of the original pointer have to be deemed invalid after
calling realloc.

 

[Joe Wright]

Of course it can make that assumption. malloc, if successful,
always return a pointer to fresh storage. realloc may not, but any
copies of the original pointer have to be deemed invalid after
calling realloc.

Our realloc can be a misbehaving child and needs attention. Consider..

int *ptr;
ptr = malloc(100 * sizeof *prt);
ptr = realloc(ptr, 200 * sizeof *ptr);

Assume malloc works and then realloc fails. We'll have ptr set to NULL
and no reference to the memory malloc gave us. A leak!

 

[pete]

You lose, so pony up.

That would be if his voice was only a little horse.

 

[CBFalconer]

That would be if his voice was only a little horse.

Can you write that as an e quine?

 

[CBFalconer]

.... snip ...

Our realloc can be a misbehaving child and needs attention.
Consider..

int *ptr;
ptr = malloc(100 * sizeof *prt);
ptr = realloc(ptr, 200 * sizeof *ptr);

Assume malloc works and then realloc fails. We'll have ptr set
to NULL and no reference to the memory malloc gave us. A leak!

So you never misuse realloc in that manner. Instead:

if (tmp = realloc(ptr, 200 * sizeof *ptr)) ptr = tmp;
else announcememoryshortage();

no leak.

 

[Keith Thompson]

So you never misuse realloc in that manner. Instead:

if (tmp = realloc(ptr, 200 * sizeof *ptr)) ptr = tmp;
else announcememoryshortage();

no leak.

Storing the result of realloc() in a separate variable is an excellent
habit. In practice, though, it may not turn out to be useful. It's
possible for a program to respond to a realloc() failure by falling
back to some less memory-intensive algorithm that uses the previously
allocated object (similarly for malloc() failuers), but it's more
likely to do some cleanup and bail out.

On the other hand, you might need information in the previously
allocated object to do the cleanup.

 

[Joe Wright]

Joe Wright wrote:
... snip ...

So you never misuse realloc in that manner. Instead:

if (tmp = realloc(ptr, 200 * sizeof *ptr)) ptr = tmp;
else announcememoryshortage();

no leak.

Yes, of course.

 

[Old Wolf]

Can you write that as an e quine?

You've really got the bit between your teeth now.
But I fear we're getting a bit far from the mane thread.

 

[Richard Bos]

That would be if his voice was only a little horse.

Perhaps he has a little colt.

Richard

 

[Chris McDonald]

Perhaps he has a little colt.

That would be a filly lame excuse.