Question about the *= (and similar) operator

[spibou]

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

[Chris McDonald]

sp****@gmail.com writes:

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

Write a small C program and try it.
The learning will provide benefits.

--
Chris.

[spibou]

Chris McDonald wrote:

sp****@gmail.com writes:

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

Write a small C program and try it.
The learning will provide benefits.

It wouldn't provide any more benefits than what I would get from
a reply here. Plus experiments are a dangerous way of learning
about C unless one knows beforehand that the behaviour being
investigated
is determined by the standard. If that's not the case then one will not
know if what he observes is standard or implementation defined or
undefined which just happened to work in a specific way under a
specific
compiler on a specific platform. For all I know , whether "expression"
is
parenthesized or not in "a *= expression" , is implementation defined
and
if one wants to achieve portability one should include parentheses in
the
code whenever the standard operator precedence does not give the
desired
result.

Spiros Bousbouras

[Giannis Papadopoulos]

sp****@gmail.com wrote:

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

ISO C99 draft (N1124) §6.5.16.2:
A compound assignment of the form E1 op = E2 differs from the simple
assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
evaluated only once.
--
one's freedom stops where others' begin

Giannis Papadopoulos
Computer and Communications Engineering dept. (CCED)
University of Thessaly
http://dop.freegr.net/

[Richard Tobin]

In article <11**********************@g10g2000cwb.googlegroups .com>,
<sp****@gmail.com> wrote:

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

The latter would only be plausible if *= was some kind of macro. If
you could define infix macros and did

#define-infix x*=y x=x*y

then a*=b+c might expand to a=a*b+c.

But C operators are not like macros. The only question is the
relative precedence of *= and +. It will either be

(a *= b) + c, which is equivalent to (a = a*b) + c,
or
a *= (b + c), which is equivalent to a = a * (b+c).

In fact, it's a = a * (b + c), because the assignment operators all
have lower precedence than the arithmetic operators.

-- Richard

[Richard Tobin]

In article <e6**********@volcano1.grnet.gr>,
Giannis Papadopoulos <ip******@inf.uth.gr> wrote:

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

A compound assignment of the form E1 op = E2 differs from the simple
assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
evaluated only once.

That's not very enlightening, since it doesn't answer the question
of whether E2 is b or b+c. In particular, the answer is different
for a *= b,c.

-- Richard

[Giannis Papadopoulos]

Richard Tobin wrote:

In article <e6**********@volcano1.grnet.gr>,
Giannis Papadopoulos <ip******@inf.uth.gr> wrote:

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

A compound assignment of the form E1 op = E2 differs from the simple
assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
evaluated only once.

That's not very enlightening, since it doesn't answer the question
of whether E2 is b or b+c. In particular, the answer is different
for a *= b,c.

-- Richard

It says (E2) so why should it be further clarified?

--
one's freedom stops where others' begin

Giannis Papadopoulos
Computer and Communications Engineering dept. (CCED)
University of Thessaly
http://dop.freegr.net/

[Chris McDonald]

sp****@gmail.com writes:

Chris McDonald wrote:

sp****@gmail.com writes:

>In the statement "a *= expression" is expression assumed to be
>parenthesized ? For example if I write "a *= b+c" is this the same
>as "a = a * (b+c)" or "a = a * b+c" ?

Write a small C program and try it.
The learning will provide benefits.

It wouldn't provide any more benefits than what I would get from
a reply here. Plus experiments are a dangerous way of learning
about C unless one knows beforehand that the behaviour being
investigated
is determined by the standard. If that's not the case then one will not
know if what he observes is standard or implementation defined or
undefined which just happened to work in a specific way under a
specific
compiler on a specific platform. For all I know , whether "expression"
is
parenthesized or not in "a *= expression" , is implementation defined
and
if one wants to achieve portability one should include parentheses in
the
code whenever the standard operator precedence does not give the
desired
result.

Sorry, politely, this is bordering on the absurd.
You do not trust anything you observe from experiments,
you do not trust anything you get from a reply here,
you do not trust anything you investigate to be conforming.

OK, it's your choice to be so suspicious and pedantic, but it's unclear
what you, or the OP, should ever trust.

Will you trust your own interpretation of the standard?
Will you trust anyone's interpretation of the standard?
And if you do trust your own or anyone else's interpretation of the standard,
how did you gain that trust?

If every commodity compiler such as MS-Studio or gcc chose to implement
the above assignment in an implementation defined fashion, then how is
anyone to rise to the level of even a basic user?

Given the nature of the OP's original question, it's clear to anyone
that a basic experiment, for varying values of a, b, and c, will reveal
far more insight than all the anal reflection in the world.

--
Chris.

[Rafael Almeida]

On 13 Jun 2006 15:42:52 -0700
sp****@gmail.com wrote:

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

If you find this confusing why not simple use parenthesis or not use
the *= (and like) operator at all?

[spibou]

Richard Tobin wrote:

In article <e6**********@volcano1.grnet.gr>,
Giannis Papadopoulos <ip******@inf.uth.gr> wrote:

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

A compound assignment of the form E1 op = E2 differs from the simple
assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
evaluated only once.

That's not very enlightening, since it doesn't answer the question
of whether E2 is b or b+c. In particular, the answer is different
for a *= b,c.

I don't see any way to parse the expression "a *= b+c" so that E2 turns
out to be just b.

[Richard Tobin]

In article <e6**********@volcano1.grnet.gr>,
Giannis Papadopoulos <ip******@inf.uth.gr> wrote:

A compound assignment of the form E1 op = E2 differs from the simple
assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
evaluated only once.

That's not very enlightening, since it doesn't answer the question
of whether E2 is b or b+c. In particular, the answer is different
for a *= b,c.

It says (E2) so why should it be further clarified?

Your reasoning would lead to the (wrong) conclusion that a *= b,c is
equivalent to a = a * (b,c).

Yes, you put parentheses around E2, but what *is* E2? Is it b
or b op c?

The standard answers the question by means of the sequence of
productions in section 6.5. a *= b + c is parsed as a *= (b + c)
because the the right operand of an assignment operator can be an
additive expression, which b + c is; whereas the left operand of an
additive expression must be an additive expression, which a *= b
isn't.

-- Richard

[Richard Tobin]

In article <11*********************@f14g2000cwb.googlegroups. com>,
<sp****@gmail.com> wrote:

>A compound assignment of the form E1 op = E2 differs from the simple
>assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
>evaluated only once.

That's not very enlightening, since it doesn't answer the question
of whether E2 is b or b+c. In particular, the answer is different
for a *= b,c.

I don't see any way to parse the expression "a *= b+c" so that E2 turns
out to be just b.

There isn't. But to find that out you have to look at the grammar.
That's why I said that the quoted sentence was not very enlightening.

-- Richard

[Keith Thompson]

sp****@gmail.com writes:

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

All assignment operators, including "*=" and ordinary "=", have the
same precedence.

Just as "a = b + c" means "a = (b + c)", "a *= b + c" means "a *= (b + c)".

Your C textbook should have an operator precedence table or equivalent.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.

[spibou]

Chris McDonald wrote:

sp****@gmail.com writes:

Chris McDonald wrote:

sp****@gmail.com writes:

>In the statement "a *= expression" is expression assumed to be
>parenthesized ? For example if I write "a *= b+c" is this the same
>as "a = a * (b+c)" or "a = a * b+c" ?

Write a small C program and try it.
The learning will provide benefits.

It wouldn't provide any more benefits than what I would get from
a reply here. Plus experiments are a dangerous way of learning
about C unless one knows beforehand that the behaviour being
investigated
is determined by the standard. If that's not the case then one will not
know if what he observes is standard or implementation defined or
undefined which just happened to work in a specific way under a
specific
compiler on a specific platform. For all I know , whether "expression"
is
parenthesized or not in "a *= expression" , is implementation defined
and
if one wants to achieve portability one should include parentheses in
the
code whenever the standard operator precedence does not give the
desired
result.

Sorry, politely, this is bordering on the absurd.
You do not trust anything you observe from experiments,
you do not trust anything you get from a reply here,
you do not trust anything you investigate to be conforming.

I don't see how the above statements follow from what I said.
OK, it's your choice to be so suspicious and pedantic, but it's unclear
what you, or the OP, should ever trust.
I don't feel that the words pedantic and suspicious apply at all to
what I said.
Will you trust your own interpretation of the standard?
Will you trust anyone's interpretation of the standard?
And if you do trust your own or anyone else's interpretation of the standard,
how did you gain that trust?
These qustions are outside the topic of the thread.
If every commodity compiler such as MS-Studio or gcc chose to implement
the above assignment in an implementation defined fashion, then how is
anyone to rise to the level of even a basic user?
I suggested the possibility that the choice between *only 2*
interpretations
could be up to individual implementations. Even without such a
restriction
I don't see how it would have anything to do with one's ability to rise
to the
level of basic user.
Given the nature of the OP's original question, it's clear to anyone
that a basic experiment, for varying values of a, b, and c, will reveal
far more insight than all the anal reflection in the world.

I can't imagine what insight you think it would offer but I'm pretty
sure it wouldn't answer my question. In any case why don't you run
the experiment and tell us what insight you gained ?

Spiros Bousbouras

[spibou]

Rafael Almeida wrote:

On 13 Jun 2006 15:42:52 -0700
sp****@gmail.com wrote:

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

If you find this confusing why not simple use parenthesis or not use
the *= (and like) operator at all?

Because I like succinctness. Plus I was curious.

[spibou]

Keith Thompson wrote:

sp****@gmail.com writes:

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

All assignment operators, including "*=" and ordinary "=", have the
same precedence.

Just as "a = b + c" means "a = (b + c)", "a *= b + c" means "a *= (b + c)".

Your C textbook should have an operator precedence table or equivalent.

Well , I saw my question as one about semantics rather than operator
precedence.

[Rafael Almeida]

On 13 Jun 2006 17:15:17 -0700
sp****@gmail.com wrote:

Rafael Almeida wrote:

If you find this confusing why not simple use parenthesis or not use
the *= (and like) operator at all?

Because I like succinctness. Plus I was curious.

I rather like legibility. Being curious is ok, though.

[Rafael Almeida]

On 13 Jun 2006 17:20:13 -0700
sp****@gmail.com wrote:

Keith Thompson wrote:

All assignment operators, including "*=" and ordinary "=", have the
same precedence.

Just as "a = b + c" means "a = (b + c)", "a *= b + c" means "a *= (b + c)".

Your C textbook should have an operator precedence table or equivalent.

Well , I saw my question as one about semantics rather than operator
precedence.

Are you saying keith didn't answer your question?

[Keith Thompson]

sp****@gmail.com writes:

Keith Thompson wrote:

sp****@gmail.com writes:

> In the statement "a *= expression" is expression assumed to be
> parenthesized ? For example if I write "a *= b+c" is this the same
> as "a = a * (b+c)" or "a = a * b+c" ?

All assignment operators, including "*=" and ordinary "=", have the
same precedence.

Just as "a = b + c" means "a = (b + c)", "a *= b + c" means "a *= (b + c)".

Your C textbook should have an operator precedence table or equivalent.

Well , I saw my question as one about semantics rather than operator
precedence.

No, it was a question about operator precedence (actually about how
expressions are parsed, since the standard doesn't talk about
precedence as such). The semantics of the expression follow from the
way it's parsed (and from the semantics of the operations themselves).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.

[spibou]

Richard Tobin wrote:

In article <e6**********@volcano1.grnet.gr>,
Giannis Papadopoulos <ip******@inf.uth.gr> wrote:

A compound assignment of the form E1 op = E2 differs from the simple
assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
evaluated only once. That's not very enlightening, since it doesn't answer the question
of whether E2 is b or b+c. In particular, the answer is different
for a *= b,c.

It says (E2) so why should it be further clarified?

Your reasoning would lead to the (wrong) conclusion that a *= b,c is
equivalent to a = a * (b,c).

Yes, you put parentheses around E2, but what *is* E2? Is it b
or b op c?

In the general case , E2 would be the right operand of the *= operator.
So in the expression "a *= b,c" we use operator precedence to decide
that the right operand of the *= operator is b and combining that
with what Giannis said we conclude that "a *= b" is the same as
"a = a * (b)".
The standard answers the question by means of the sequence of
productions in section 6.5. a *= b + c is parsed as a *= (b + c)
because the the right operand of an assignment operator can be an
additive expression, which b + c is; whereas the left operand of an
additive expression must be an additive expression, which a *= b
isn't.
Actually this is something which does not answer my question. I *knew*
when I made the opening post that "a *= b + c" is parsed as "a *= (b +
c)"
ie that the right hand operand of *= is "b+c" but I wasn't completely
certain how the right hand operand is to be used to alter the value of
the
left hand operand. See also the comment below.
Richard Tobin wrote:
In article <11**********************@g10g2000cwb.googlegroups .com>,
<sp****@gmail.com> wrote:

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

The latter would only be plausible if *= was some kind of macro. If
you could define infix macros and did

#define-infix x*=y x=x*y

then a*=b+c might expand to a=a*b+c.

But C operators are not like macros. The only question is the
relative precedence of *= and +. It will either be

(a *= b) + c, which is equivalent to (a = a*b) + c,
or
a *= (b + c), which is equivalent to a = a * (b+c).

In fact, it's a = a * (b + c), because the assignment operators all
have lower precedence than the arithmetic operators.

Yes , after the explanations from various people I see now that the
alternative I had in mind was rather implausible. But I'm glad I
verified it.

[spibou]

Keith Thompson wrote:

sp****@gmail.com writes:

Keith Thompson wrote:

sp****@gmail.com writes:
> In the statement "a *= expression" is expression assumed to be
> parenthesized ? For example if I write "a *= b+c" is this the same
> as "a = a * (b+c)" or "a = a * b+c" ?

All assignment operators, including "*=" and ordinary "=", have the
same precedence.

Just as "a = b + c" means "a = (b + c)", "a *= b + c" means "a *= (b + c)".

Your C textbook should have an operator precedence table or equivalent.
Well , I saw my question as one about semantics rather than operator
precedence.

No, it was a question about operator precedence (actually about how
expressions are parsed, since the standard doesn't talk about
precedence as such). The semantics of the expression follow from the
way it's parsed (and from the semantics of the operations themselves).

Perhaps that's how you read it but precedence was not what I was
confused
about. See below.
sp****@gmail.com wrote:
Richard Tobin wrote:

In article <e6**********@volcano1.grnet.gr>,
Giannis Papadopoulos <ip******@inf.uth.gr> wrote:

>> A compound assignment of the form E1 op = E2 differs from the simple
>> assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
>> evaluated only once.

> That's not very enlightening, since it doesn't answer the question
> of whether E2 is b or b+c. In particular, the answer is different
> for a *= b,c.

It says (E2) so why should it be further clarified?

Your reasoning would lead to the (wrong) conclusion that a *= b,c is
equivalent to a = a * (b,c).

Yes, you put parentheses around E2, but what *is* E2? Is it b
or b op c?

In the general case , E2 would be the right operand of the *= operator.
So in the expression "a *= b,c" we use operator precedence to decide
that the right operand of the *= operator is b and combining that
with what Giannis said we conclude that "a *= b" is the same as
"a = a * (b)".

The standard answers the question by means of the sequence of
productions in section 6.5. a *= b + c is parsed as a *= (b + c)
because the the right operand of an assignment operator can be an
additive expression, which b + c is; whereas the left operand of an
additive expression must be an additive expression, which a *= b
isn't.

Actually this is something which does not answer my question. I *knew*
when I made the opening post that "a *= b + c" is parsed as "a *= (b +
c)"
ie that the right hand operand of *= is "b+c" but I wasn't completely
certain how the right hand operand is to be used to alter the value of
the
left hand operand. See also the comment below.
Richard Tobin wrote:

In article <11**********************@g10g2000cwb.googlegroups .com>,
<sp****@gmail.com> wrote:

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

The latter would only be plausible if *= was some kind of macro. If
you could define infix macros and did

#define-infix x*=y x=x*y

then a*=b+c might expand to a=a*b+c.

But C operators are not like macros. The only question is the
relative precedence of *= and +. It will either be

(a *= b) + c, which is equivalent to (a = a*b) + c,
or
a *= (b + c), which is equivalent to a = a * (b+c).

In fact, it's a = a * (b + c), because the assignment operators all
have lower precedence than the arithmetic operators.

Yes , after the explanations from various people I see now that the
alternative I had in mind was rather implausible. But I'm glad I
verified it.

[spibou]

Rafael Almeida wrote:

On 13 Jun 2006 17:20:13 -0700
sp****@gmail.com wrote:

Keith Thompson wrote:

All assignment operators, including "*=" and ordinary "=", have the
same precedence.

Just as "a = b + c" means "a = (b + c)", "a *= b + c" means "a *= (b + c)".

Your C textbook should have an operator precedence table or equivalent.

Well , I saw my question as one about semantics rather than operator
precedence.

Are you saying keith didn't answer your question?

By the time I read Ketih's post I had read others which had answered my
question. I'm not sure if Keith's post would have done it on its own. I
was
simply saying that he didn't understand what I was confused about.

[spibou]

Giannis Papadopoulos wrote:

sp****@gmail.com wrote:

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

ISO C99 draft (N1124) §6.5.16.2:
A compound assignment of the form E1 op = E2 differs from the simple
assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
evaluated only once.

Although that answers my question I'm confused about the "only once"
part. How many times is E1 evaluated in "E1 = E1 op (E2)" ? Or to be
more specific how many times is "a" evaluated in "a = a * (b+c)" ?

[Thomas J. Gritzan]

sp****@gmail.com schrieb:

Giannis Papadopoulos wrote:

sp****@gmail.com wrote:

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

ISO C99 draft (N1124) §6.5.16.2:
A compound assignment of the form E1 op = E2 differs from the simple
assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
evaluated only once.

Although that answers my question I'm confused about the "only once"
part. How many times is E1 evaluated in "E1 = E1 op (E2)" ? Or to be
more specific how many times is "a" evaluated in "a = a * (b+c)" ?

Well, a appears two times, so its evaluated two times. Simple?

Thomas

[spibou]

Thomas J. Gritzan wrote:

sp****@gmail.com schrieb:

Giannis Papadopoulos wrote:

sp****@gmail.com wrote:
In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

ISO C99 draft (N1124) §6.5.16.2:
A compound assignment of the form E1 op = E2 differs from the simple
assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
evaluated only once.

Although that answers my question I'm confused about the "only once"
part. How many times is E1 evaluated in "E1 = E1 op (E2)" ? Or to be
more specific how many times is "a" evaluated in "a = a * (b+c)" ?

Well, a appears two times, so its evaluated two times. Simple?

Nope ! Perhaps I have the wrong idea about what "evaluated" means.
Could you explain that ? Consider something simpler first: "a=1". What
is the evaluation of "a" in this case ?

[Keith Thompson]

sp****@gmail.com writes:

Giannis Papadopoulos wrote:

sp****@gmail.com wrote:

> In the statement "a *= expression" is expression assumed to be
> parenthesized ? For example if I write "a *= b+c" is this the same
> as "a = a * (b+c)" or "a = a * b+c" ?

ISO C99 draft (N1124) §6.5.16.2:
A compound assignment of the form E1 op = E2 differs from the simple
assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
evaluated only once.

Although that answers my question I'm confused about the "only once"
part. How many times is E1 evaluated in "E1 = E1 op (E2)" ? Or to be
more specific how many times is "a" evaluated in "a = a * (b+c)" ?

In "a = a * (b + c)", a is evaluated twice -- but in this case it
doesn't matter (unless a happens to be volatile).

This becomes more relevant if the expression has side effects.

#include <stdio.h>

int func(char *message)
{
printf("In func(\"%s\")\n", message);
return 0;
}

int main(void)
{
int arr[1] = { 0 };

arr[func("Not using *=")] = arr[func("Not using *=")] * 42;
arr[func("Using *=")] *= 42;

return 0;
}

This prints:

In func("Not using *=")
In func("Not using *=")
In func("Using *=")

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.

[Andrew Poelstra]

On 2006-06-14, sp****@gmail.com <sp****@gmail.com> wrote:

Chris McDonald wrote:

sp****@gmail.com writes:

>Chris McDonald wrote:

>> sp****@gmail.com writes:
>>
>> >In the statement "a *= expression" is expression assumed to be
>> >parenthesized ? For example if I write "a *= b+c" is this the same
>> >as "a = a * (b+c)" or "a = a * b+c" ?
>>
>> Write a small C program and try it.
>> The learning will provide benefits.
>>

>It wouldn't provide any more benefits than what I would get from
>a reply here. Plus experiments are a dangerous way of learning
>about C unless one knows beforehand that the behaviour being
>investigated
>is determined by the standard. If that's not the case then one will not
>know if what he observes is standard or implementation defined or
>undefined which just happened to work in a specific way under a
>specific
>compiler on a specific platform. For all I know , whether "expression"
>is
>parenthesized or not in "a *= expression" , is implementation defined
>and
>if one wants to achieve portability one should include parentheses in
>the
>code whenever the standard operator precedence does not give the
>desired
>result.

Sorry, politely, this is bordering on the absurd.
You do not trust anything you observe from experiments,
you do not trust anything you get from a reply here,
you do not trust anything you investigate to be conforming.

I don't see how the above statements follow from what I said.

OK, it's your choice to be so suspicious and pedantic, but it's unclear
what you, or the OP, should ever trust.

I don't feel that the words pedantic and suspicious apply at all to
what I said.

Will you trust your own interpretation of the standard?
Will you trust anyone's interpretation of the standard?
And if you do trust your own or anyone else's interpretation of the standard,
how did you gain that trust?

These qustions are outside the topic of the thread.

If every commodity compiler such as MS-Studio or gcc chose to implement
the above assignment in an implementation defined fashion, then how is
anyone to rise to the level of even a basic user?

I suggested the possibility that the choice between *only 2*
interpretations
could be up to individual implementations. Even without such a
restriction
I don't see how it would have anything to do with one's ability to rise
to the
level of basic user.

This is a basic question. If you can't understand it, (or if implementation
differences make it impossible to understand it), you can't become a basic
user.

Given the nature of the OP's original question, it's clear to anyone
that a basic experiment, for varying values of a, b, and c, will reveal
far more insight than all the anal reflection in the world.

I can't imagine what insight you think it would offer but I'm pretty
sure it wouldn't answer my question. In any case why don't you run
the experiment and tell us what insight you gained ?

It will answer your question, and Chris won't run the experiment because
he knows C, and already knows the answer. He's merely encouraging you to
figure it out yourself, and hence learn to teach yourself.

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

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
I know that area of town like the back of my head.

[spibou]

Keith Thompson wrote:

sp****@gmail.com writes:

Giannis Papadopoulos wrote:

sp****@gmail.com wrote:
> In the statement "a *= expression" is expression assumed to be
> parenthesized ? For example if I write "a *= b+c" is this the same
> as "a = a * (b+c)" or "a = a * b+c" ?

ISO C99 draft (N1124) §6.5.16.2:
A compound assignment of the form E1 op = E2 differs from the simple
assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
evaluated only once.
Although that answers my question I'm confused about the "only once"
part. How many times is E1 evaluated in "E1 = E1 op (E2)" ? Or to be
more specific how many times is "a" evaluated in "a = a * (b+c)" ?

In "a = a * (b + c)", a is evaluated twice -- but in this case it
doesn't matter (unless a happens to be volatile).

I take it that if it's volatile then its value may change between
evaluations.
This becomes more relevant if the expression has side effects.

#include <stdio.h>

int func(char *message)
{
printf("In func(\"%s\")\n", message);
return 0;
}

int main(void)
{
int arr[1] = { 0 };

arr[func("Not using *=")] = arr[func("Not using *=")] * 42;
arr[func("Using *=")] *= 42;

return 0;
}

This prints:

In func("Not using *=")
In func("Not using *=")
In func("Using *=")
That was very enlightening. Thank you.

Andrew Poelstra wrote:
On 2006-06-14, sp****@gmail.com <sp****@gmail.com> wrote:

Chris McDonald wrote:

If every commodity compiler such as MS-Studio or gcc chose to implement
the above assignment in an implementation defined fashion, then how is
anyone to rise to the level of even a basic user?

I , spibou the great , wrote:

I suggested the possibility that the choice between *only 2*
interpretations
could be up to individual implementations. Even without such a
restriction
I don't see how it would have anything to do with one's ability to rise
to the
level of basic user.

This is a basic question. If you can't understand it, (or if implementation
differences make it impossible to understand it), you can't become a basic
user.

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.

Given the nature of the OP's original question, it's clear to anyone
that a basic experiment, for varying values of a, b, and c, will reveal
far more insight than all the anal reflection in the world.

I can't imagine what insight you think it would offer but I'm pretty
sure it wouldn't answer my question. In any case why don't you run
the experiment and tell us what insight you gained ?

It will answer your question, and Chris won't run the experiment because
he knows C, and already knows the answer. He's merely encouraging you to
figure it out yourself, and hence learn to teach yourself.

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.
If you give a man a fish, he'll eat for a day...

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.

Spiros Bousbouras

[Keith Thompson]

sp****@gmail.com writes:

Keith Thompson wrote:

[...]

In "a = a * (b + c)", a is evaluated twice -- but in this case it
doesn't matter (unless a happens to be volatile).

Yes, that too. Volatility goes both ways: external mechanisms can
change a volatile variable's behind the program's back, and any access
(either a read or a write) of a volatile variable is considered a side
effect, so it must actually happen. Given:

{
volatile int x;
int y;
x = 10;
x = 20;
y = x;
printf("y = %d\n", y);
}

the generated code must actually store the values 10 and 20 to x, and
then read x to store its value in y. Without the "volatile", the
compiler could legally entire chunk of code to:

puts("y = 20");

(In practice, there's no good reason to apply "volatile" to an auto
object; more commonly it might be applied to an object at a specified
address, such as a hardware register of some kind.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.

[jaysome]

On Wed, 14 Jun 2006 08:21:54 GMT, Keith Thompson <ks***@mib.org>
wrote:

sp****@gmail.com writes:

Keith Thompson wrote:

[...]

In "a = a * (b + c)", a is evaluated twice -- but in this case it
doesn't matter (unless a happens to be volatile).

Yes, that too. Volatility goes both ways: external mechanisms can
change a volatile variable's behind the program's back, and any access
(either a read or a write) of a volatile variable is considered a side
effect, so it must actually happen. Given:

{
volatile int x;
int y;
x = 10;
x = 20;
y = x;
printf("y = %d\n", y);
}

the generated code must actually store the values 10 and 20 to x, and
then read x to store its value in y. Without the "volatile", the
compiler could legally entire chunk of code to:

puts("y = 20");

(In practice, there's no good reason to apply "volatile" to an auto
object; more commonly it might be applied to an object at a specified
address, such as a hardware register of some kind.)

I can't think of any reason why a volatile auto object that is not a
pointer and is not pointed to by a suitably typed pointer could ever
be useful. Sure, C may allow that, but what use could it ever be?

--
jay

[Keith Thompson]

jaysome <ja*****@spamcop.net> writes:

On Wed, 14 Jun 2006 08:21:54 GMT, Keith Thompson <ks***@mib.org>
wrote:

[...]

(In practice, there's no good reason to apply "volatile" to an auto
object; more commonly it might be applied to an object at a specified
address, such as a hardware register of some kind.)

I can't think of any reason why a volatile auto object that is not a
pointer and is not pointed to by a suitably typed pointer could ever
be useful. Sure, C may allow that, but what use could it ever be?

Possibly you might pass the address of the object to some
system-specific routine that causes the system to treat the object in
some odd way. I suppose that's nearly equivalent to your "pointed to
by a suitably typed pointer".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.

[Nick Keighley]

Chris McDonald wrote:

sp****@gmail.com writes:

Chris McDonald wrote:

sp****@gmail.com writes: >In the statement "a *= expression" is expression assumed to be
>parenthesized ? For example if I write "a *= b+c" is this the same
>as "a = a * (b+c)" or "a = a * b+c" ?

Write a small C program and try it.
The learning will provide benefits.

It wouldn't provide any more benefits than what I would get from
a reply here. Plus experiments are a dangerous way of learning
about C unless one knows beforehand that the behaviour being
investigated
is determined by the standard. If that's not the case then one will not
know if what he observes is standard or implementation defined or
undefined which just happened to work in a specific way under a
specific compiler on a specific platform. For all I know , whether
"expression" is parenthesized or not in "a *= expression" , is
implementation defined
and if one wants to achieve portability one should include parentheses in
the code whenever the standard operator precedence does not give the
desired result.

Sorry, politely, this is bordering on the absurd.

no. He is being entirely correct
You do not trust anything you observe from experiments,
well experiments on implementations don't necessarily tell you if you
are
observing standard behaviour or implementation behaviour.

*0 = 1;
i= 2; j = i++ + i++;
k = 1 / 0;

They may all give a particular result on a particular implementation
you do not trust anything you get from a reply here,
? then why was he asking? clc is pretty good at coming to some sort
of concensus, if not definitive answer.
you do not trust anything you investigate to be conforming.
well it's a base assumption
OK, it's your choice to be so suspicious and pedantic, but it's unclear
what you, or the OP, should ever trust.

Will you trust your own interpretation of the standard?
the standard is a formal document and in principal can give
unambiguous,
interpretation-free answers
Will you trust anyone's interpretation of the standard?
someone else may be better at reading the formal langauge of the
standard
than the OP. Note the OP was asking what the standard said so
presumably
he hadn't read it.
And if you do trust your own or anyone else's interpretation of the standard,
how did you gain that trust?
reading the standard then asking well informed people if your
interpreataion is
correct. After clc you could go to comp.lang.c.std where people form
the ISO
standard actually hang out.
If every commodity compiler such as MS-Studio or gcc chose to implement
the above assignment in an implementation defined fashion, then how is
anyone to rise to the level of even a basic user?
well presumably MS and GNU *try* to be standards compliant.
Given the nature of the OP's original question, it's clear to anyone
that a basic experiment, for varying values of a, b, and c, will reveal
far more insight than all the anal reflection in the world.

with respect, nonsense.
--
Nick Keighley

-pedantic
This option is not intended to be useful; it exists only to satisfy
pedants who would otherwise claim that GNU CC fails to support the
ANSI standard.
(Using and Porting GNU CC)

in comp.lang.c, the very people most capable of making the inference
are those least likely to make it. This newsgroup considers pedantry
to be an art form.
Richard Heathfield

[Harald van Dijk]

jaysome wrote:

I can't think of any reason why a volatile auto object that is not a
pointer and is not pointed to by a suitably typed pointer could ever
be useful. Sure, C may allow that, but what use could it ever be?

It can be necessary for some uses of longjmp.

[jaysome]

On 14 Jun 2006 02:21:25 -0700, "Harald van D?k" <tr*****@gmail.com>
wrote:

jaysome wrote:

I can't think of any reason why a volatile auto object that is not a
pointer and is not pointed to by a suitably typed pointer could ever
be useful. Sure, C may allow that, but what use could it ever be?

It can be necessary for some uses of longjmp.

Can you give an example?

--
jay

[Richard Tobin]

In article <11**********************@p79g2000cwp.googlegroups .com>,
<sp****@gmail.com> wrote:

Well, a appears two times, so its evaluated two times. Simple?

Nope ! Perhaps I have the wrong idea about what "evaluated" means.
Could you explain that ? Consider something simpler first: "a=1". What
is the evaluation of "a" in this case ?

If a is an ordinary variable, then evaluating it doesn't amount to
much. But if a is an expression such as array[index++], then
evaluating it has side effects and these will happen twice in
array[index++] = array[index++] + 1 but only once in array[index++] += 1.

-- Richard

[Richard Tobin]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

No, it was a question about operator precedence

Perhaps not...

(1) C operators work like an infix notation for functions
(2) operator precedence determines which arguments go with with function.

The OP seemed to have doubts about the truth of (1) - he gave a
possibility that would imply they worked like macros - so he hadn't
got to the point where his question would be about operator
precedence.

-- Richard

[Harald van Dijk]

jaysome wrote:

On 14 Jun 2006 02:21:25 -0700, "Harald van D?k" <tr*****@gmail.com>
wrote:

jaysome wrote:

I can't think of any reason why a volatile auto object that is not a
pointer and is not pointed to by a suitably typed pointer could ever
be useful. Sure, C may allow that, but what use could it ever be?

It can be necessary for some uses of longjmp.

Can you give an example?

#include <stdio.h>
#include <setjmp.h>

int main(void) {
jmp_buf buf;
#if 0
volatile
#endif
int x = 0;
if(setjmp(buf) == 0) {
x = 1;
longjmp(buf, 0);
}
printf("%d\n", x);
}

My compiler assumes that since longjmp() can't ever return, printf()
will always print 0, and doesn't re-read x. This is a legitimate
optimisation unless volatile is used.

[James Dow Allen]

sp****@gmail.com wrote:

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

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.

You indicate that you didn't want to experiment out of fear the result
was
compiler dependent! Again, if you could imagine that such a simple
expression
could be compiler dependent you've acquired a poor impression of C.

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.

C started out with a philosophy that is the antithesis of languages
like C++.
In the "old days", C textbooks happily acknowledged that some details
were machine-dependent and enocuraged experimentation if you weren't
sure how your machine worked!

Standardization has its purpose, but I think you'll be a happier and
more
successful C programmer if you can acquire some of the more
"old fashioned" C spirit.

Take this message to heart and soon you'll be doing things much harder
than
a *= b+c
without needing help from Usenet.

James Dow Allen

[CBFalconer]

James Dow Allen wrote:

.... snip ...
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.

Well? You haven't been doing C for long, I see :-)

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[Kenneth Brody]

James Dow Allen wrote:
[...]

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

"Conceivable"? Of course!

"Likely, in a 'real-world' language"? Probably not.

Check out languages like INTERCAL and BrainF*** if you want to see
just what sort of languages people come up with.

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Andrew Poelstra]

On 2006-06-14, sp****@gmail.com <sp****@gmail.com> wrote:

Andrew Poelstra wrote:

On 2006-06-14, sp****@gmail.com <sp****@gmail.com> wrote:

>
> Chris McDonald wrote: >> If every commodity compiler such as MS-Studio or gcc chose to implement
>> the above assignment in an implementation defined fashion, then how is
>> anyone to rise to the level of even a basic user?
>

I , spibou the great , wrote:

> I suggested the possibility that the choice between *only 2*
> interpretations
> could be up to individual implementations. Even without such a
> restriction
> I don't see how it would have anything to do with one's ability to rise
> to the
> level of basic user.
>

This is a basic question. If you can't understand it, (or if implementation
differences make it impossible to understand it), you can't become a basic
user.

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.

>> Given the nature of the OP's original question, it's clear to anyone
>> that a basic experiment, for varying values of a, b, and c, will reveal
>> far more insight than all the anal reflection in the world.
>
> I can't imagine what insight you think it would offer but I'm pretty
> sure it wouldn't answer my question. In any case why don't you run
> the experiment and tell us what insight you gained ?
>

It will answer your question, and Chris won't run the experiment because
he knows C, and already knows the answer. He's merely encouraging you to
figure it out yourself, and hence learn to teach yourself.

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;
}

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

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.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
I know that area of town like the back of my head.

[Skarmander]

James Dow Allen wrote:

sp****@gmail.com wrote:

In the statement "a *= expression" is expression assumed to be
parenthesized ? For example if I write "a *= b+c" is this the same
as "a = a * (b+c)" or "a = a * b+c" ?

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]

"James Dow Allen" <jd*********@yahoo.com> writes:
[...]

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.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.

[James Dow Allen]

Keith Thompson wrote:

"James Dow Allen" <jd*********@yahoo.com> writes:

... The interesting part of the post was ignored, ... 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.

--
pete

[CBFalconer]

pete wrote:

James Dow Allen wrote:

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

You have a horse voice.

You lose, so pony up.

--
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Keith Thompson]

"James Dow Allen" <jd*********@yahoo.com> writes:

Keith Thompson wrote:

"James Dow Allen" <jd*********@yahoo.com> writes:

> ... The interesting part of the post was ignored, ... 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.

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.

Ok, you found a bug in gcc. See <http://gcc.gnu.org/bugzilla/>.
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.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.

[CBFalconer]

Keith Thompson wrote:

"James Dow Allen" <jd*********@yahoo.com> writes:

.... snip ...

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.

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.

--
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Joe Wright]

CBFalconer wrote:

Keith Thompson wrote:

"James Dow Allen" <jd*********@yahoo.com> writes:

... snip ...

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.

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!

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[pete]

CBFalconer wrote:

pete wrote:

James Dow Allen wrote:

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

You have a horse voice.

You lose, so pony up.

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

--
pete