gcc means lots of fun

QNX Newsgroups (Archives) qdn.public.qnxrtp.devtools
21

Greg Comeau <comeau@panix.com> wrote:

In article <9mr1s4$qt3$> 1@inn.qnx.com> >,
Bill Caroselli (Q-TPS) <> qtps@earthlink.net> > wrote:
I disagree. The assignment operator ‘=’ is a sequence operator. I.E. in
a = b = c;
c should always be assigned to b first and then b’s new value assigned to a.

I think that you have precedence and order of evaluation confused
with something else. The bottom line is that the code from the other
post has a problem and shouldn’t be depended upon to produce any
meaningful result. That it may have produced meaningful results
just means that you were lucky (sic).

Yes, it’s like:

int i=0;
printf("%d %d %d\n", i++, i++, i++);

What does this display? Does it do what you expect? What do you expect?

Like the previous assignment operation, it is undefined, and is bad coding
to use it.

-David

QNX Training Services
dagibbs@qnx.com

22

Perhaps this is a good time to discuss the ONLY VALID place to put the
currly braces. I’m certain that we all be in compete agreement on at least
that.

“Wojtek Lerch” <wojtek_l@yahoo.ca> wrote in message
news:9n2t60$dks$1@nntp.qnx.com…

Andrzej Kocon <> ako@box43.gnet.pl> > wrote:
On 1 Sep 2001 20:41:37 GMT, Wojtek Lerch <> wojtek_l@yahoo.ca> > wrote:

Andrzej Kocon <> ako@box43.gnet.pl> > wrote:
Although compilers should conform to the standards, this
style of coding is asking for trouble regardles of what the
standards might say about the meaning of such constructs…

I think you have it backwards. If the standard says that your code is
not correct C, it doesn’t matter whether you think it’s coded in a good
style. If your code produces undefined behaviour, it’s bad code even if
the compiler decides to generate something that that does what you
expected…

This is far more than can be concluded from my statement.

Um… I didn’t really say what exactly I concluded from your statement,
did I… > :wink:

My interpretation of what you originally said was that as long as your
code meets your criteria of good coding, it doesn’t matter what the
language standard says about it. My response was that if the language
standard says that your code is invalid, it doesn’t matter whether it
meets your criteria. But as long as your criteria include the
requirement that your code must not be invalid, there’s no real conflict
between these two statements, is there…

You may safely restrain yourself from using certain programming
constructs, on any ground, without even referring to any standard.
Your criteria may be stronger than those implemented by the compiler.

Usually, your criteria should be stronger than those implemented by
the compiler. The fact that your code compiles and works in one
environment is not a proof that it doesn’t produce undefined behaviour.
And if it does, you never know when it may stop working (unless you
wrote your compiler and have no intention of using a different one…).

A famous one is “Does the construct simplify program reading, or
understanding, or (pardon) proving it correct?” (and it does not rely
entirely on one’s taste). This is not the job of a programmer to
ponder the niceties of doubtful or tricky language expressions, valid
or not (unless he writes… a compiler).

But it is!

The job of a programmer includes fixing broken code. You can try to do
that by replacing all the code that looks tricky or doubtful to you with
code that doesn’t look tricky or doubtful; the problem is that in some
cases, invalid code may not look tricky or doubtful, and in those cases,
it’s good to be able to recognize that it is invalid. And that’s when
understanding subtleties of the language can be useful.

Even if you choose to restrict yourself to using a subset of the
language that you feel is safer or easier to understand than the full
language, it still is a good idea to make sure that the subset indeed is
a subset. Before you can safely say that you can ignore the real limits
of the language because it’s enough for you to know the limits of your
subset, you have to make sure that your subset does not cross the real
limits. And that might sometimes be difficult if you don’t understand
the full language well enough.

Perhaps I should apologize for the term “style” which, besides
being too personal, might have encouraged the “backward” conclusion.

Then perhaps I should apologize for using such a strong word…

I didn’t recommend neglecting the language definition in favour of
common sense…

I didn’t think you did – it would be against common sense, wouldn’t
it… > :slight_smile:

–
Wojtek Lerch QNX Software Systems Ltd.

23

In article <9n5hkf$43r$1@nntp.qnx.com>, David Gibbs <dagibbs@qnx.com> wrote:

Greg Comeau <> comeau@panix.com> > wrote:
In article <9mr1s4$qt3$> 1@inn.qnx.com> >,
Bill Caroselli (Q-TPS) <> qtps@earthlink.net> > wrote:
I disagree. The assignment operator ‘=’ is a sequence operator. I.E. in
a = b = c;
c should always be assigned to b first and then b’s new value assigned to a.

I think that you have precedence and order of evaluation confused
with something else. The bottom line is that the code from the other
post has a problem and shouldn’t be depended upon to produce any
meaningful result. That it may have produced meaningful results
just means that you were lucky (sic).

Yes, it’s like:

int i=0;
printf("%d %d %d\n", i++, i++, i++);

Yes, that’s the classic example… the other being something like

a = i++;

What does this display?

We don’t know.

Does it do what you expect?

We don’t expect anything.

What do you expect?

Don’t expect anything meaningful.

Like the previous assignment operation, it is undefined, and is bad coding
to use it.

_Agreed.

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?_

24

“Bill Caroselli (Q-TPS)” <qtps@earthlink.net> wrote:

Perhaps this is a good time to discuss the ONLY VALID place to put the
currly braces. I’m certain that we all be in compete agreement on at least
that.

Perhaps not, but I imagine that we would all agree that they should not
be put in places where they produce a syntax error. :slight_smile:

–
Wojtek Lerch QNX Software Systems Ltd.

25

I have been under the mistaken belief since, I guess, about 1976 that
assignments proceeded from right to left in order. I wonder if that was
true once (ante-ANSI) or did I just dream it up?

Thanks for correcting my misunderstanding.

Dean

Josh Hamacher wrote:

Just for the record, I didn’t write that code; I’m porting an existing
app, and that code was already in it. I don’t much care for that style,
either, to tell you the truth.

I did, however, think that it was legal C++ (for the same reason as
Bill; I thought the assignment operator was always evaluated
right-to-left). Thanks for enlightening me.

Josh Hamacher
FAAC Incorporated

26

Well you’re not alone: I also was under that impression. Moreover, my
Watcom language reference (p.112) says:

quote >>>
Note that, unlike most other operators, the assignment operators
associate from right to left. For example, the expression,

a += b = c

is translated as if it had been bracketed as follows:

a += (b = c)

<<< end quote

If you think about it, it does make sense, since:

(a += b) = c

would mean trying to assign (the value of) c to an expression (a += b)
which does not yield an lvalue.

But then again, my lang.ref. manual may be outdated. Besides, a compiler
implementation does not prove the standard.

regards,
rick

Dean Douthat <ddouthat@faac.com> wrote:

I have been under the mistaken belief since, I guess, about 1976 that
assignments proceeded from right to left in order. I wonder if that was
true once (ante-ANSI) or did I just dream it up?

Thanks for correcting my misunderstanding.

Dean

Josh Hamacher wrote:

Just for the record, I didn’t write that code; I’m porting an existing
app, and that code was already in it. I don’t much care for that style,
either, to tell you the truth.

I did, however, think that it was legal C++ (for the same reason as
Bill; I thought the assignment operator was always evaluated
right-to-left). Thanks for enlightening me.

Josh Hamacher
FAAC Incorporated

27

hmmm… I just scrolled back to the previous posts, and I understand now
what the discussion was about: the order of evaluation of (in this case)
(a), (b) and (c) is unspecified. That I agree with, so disregard my
previous follow-up :slight_smile:

Rick Lake <rwlake@spamfree.domain.invalid> wrote:

Well you’re not alone: I also was under that impression. Moreover, my
Watcom language reference (p.112) says:

quote
Note that, unlike most other operators, the assignment operators
associate from right to left. For example, the expression,

a += b = c

is translated as if it had been bracketed as follows:

a += (b = c)

end quote

If you think about it, it does make sense, since:

(a += b) = c

would mean trying to assign (the value of) c to an expression (a += b)
which does not yield an lvalue.

But then again, my lang.ref. manual may be outdated. Besides, a compiler
implementation does not prove the standard.

regards,
rick

Dean Douthat <> ddouthat@faac.com> > wrote:
I have been under the mistaken belief since, I guess, about 1976 that
assignments proceeded from right to left in order. I wonder if that was
true once (ante-ANSI) or did I just dream it up?

Thanks for correcting my misunderstanding.

Dean

Josh Hamacher wrote:

Just for the record, I didn’t write that code; I’m porting an existing
app, and that code was already in it. I don’t much care for that style,
either, to tell you the truth.

I did, however, think that it was legal C++ (for the same reason as
Bill; I thought the assignment operator was always evaluated
right-to-left). Thanks for enlightening me.

Josh Hamacher
FAAC Incorporated

28

In article <9n669m$kc9$1@inn.qnx.com>,
Rick Lake <rwlake@spamfree.domain.invalid> wrote:

Dean Douthat <> ddouthat@faac.com> > wrote:
I have been under the mistaken belief since, I guess, about 1976 that
assignments proceeded from right to left in order. I wonder if that was
true once (ante-ANSI) or did I just dream it up?

You’re dreaming :slight_smile:

Well you’re not alone: I also was under that impression. Moreover, my
Watcom language reference (p.112) says:

quote
Note that, unlike most other operators, the assignment operators
associate from right to left. For example, the expression,

a += b = c

is translated as if it had been bracketed as follows:

a += (b = c)

end quote

If you think about it, it does make sense, since:

(a += b) = c

would mean trying to assign (the value of) c to an expression (a += b)
which does not yield an lvalue.

But then again, my lang.ref. manual may be outdated. Besides, a compiler
implementation does not prove the standard.

You’re both right. That’s how “it” works. The problem is
that “it” doesn’t just deal with “proceeding” and "associate"ing.
It also deals with grouping, arity, precedence, order of
evaluation, sequence points, agreement points, aliasing,
optimization and interleaving.

The significant of all this buzz’y stuff is that side-effects
can happen during many C (or C++) expressions. And often, they do!

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

29

Greg Comeau wrote:

In article <9n669m$kc9$> 1@inn.qnx.com> >,
Rick Lake <> rwlake@spamfree.domain.invalid> > wrote:
Dean Douthat <> ddouthat@faac.com> > wrote:
I have been under the mistaken belief since, I guess, about 1976 that
assignments proceeded from right to left in order. I wonder if that was
true once (ante-ANSI) or did I just dream it up?

You’re dreaming > :slight_smile:

No, he’s not! I remember that, too!
My copy of K&R copyright 1978 has, in Appendix A, Section 7.14, pg. 191:
“There are a number of assignment operators, all of which group
right-to-left. …”
and in Section 18.1, pp 214-215:
“Assignment operators all have the same priority, and all group
right-to-left.”
He, like me, has been using C for long time; he just doesn’t happen to keep
all his old books :slight_smile:

I’d be curious to read the discussions in ANSI about why this was changed to be
ambiguous, as it now is, apparently…

Phil Olynyk

Well you’re not alone: I also was under that impression. Moreover, my
Watcom language reference (p.112) says:

quote
Note that, unlike most other operators, the assignment operators
associate from right to left. For example, the expression,

a += b = c

is translated as if it had been bracketed as follows:

a += (b = c)

end quote

If you think about it, it does make sense, since:

(a += b) = c

would mean trying to assign (the value of) c to an expression (a += b)
which does not yield an lvalue.

But then again, my lang.ref. manual may be outdated. Besides, a compiler
implementation does not prove the standard.

You’re both right. That’s how “it” works. The problem is
that “it” doesn’t just deal with “proceeding” and "associate"ing.
It also deals with grouping, arity, precedence, order of
evaluation, sequence points, agreement points, aliasing,
optimization and interleaving.

The significant of all this buzz’y stuff is that side-effects
can happen during many C (or C++) expressions. And often, they do!

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> > http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

30

In article <3B96D1BE.6F0E4C62@home.com>,
Phil Olynyk <pholynyk@home.com> wrote:

Greg Comeau wrote:
In article <9n669m$kc9$> 1@inn.qnx.com> >,
Rick Lake <> rwlake@spamfree.domain.invalid> > wrote:
Dean Douthat <> ddouthat@faac.com> > wrote:
I have been under the mistaken belief since, I guess, about 1976 that
assignments proceeded from right to left in order. I wonder if that was
true once (ante-ANSI) or did I just dream it up?

You’re dreaming > :slight_smile:

No, he’s not! I remember that, too!
My copy of K&R copyright 1978 has, in Appendix A, Section 7.14, pg. 191:
“There are a number of assignment operators, all of which group
right-to-left. …”
and in Section 18.1, pp 214-215:
“Assignment operators all have the same priority, and all group
right-to-left.”

And that’s correct.

He, like me, has been using C for long time; he just doesn’t happen to keep
all his old books > :slight_smile:

I’d be curious to read the discussions in ANSI about why this was changed to be
ambiguous, as it now is, apparently…

They didn’t. See what I said below.
Hint: grouping is not the only thing that occurs.

Well you’re not alone: I also was under that impression. Moreover, my
Watcom language reference (p.112) says:

quote
Note that, unlike most other operators, the assignment operators
associate from right to left. For example, the expression,

a += b = c

is translated as if it had been bracketed as follows:

a += (b = c)

end quote

If you think about it, it does make sense, since:

(a += b) = c

would mean trying to assign (the value of) c to an expression (a += b)
which does not yield an lvalue.

But then again, my lang.ref. manual may be outdated. Besides, a compiler
implementation does not prove the standard.

You’re both right. That’s how “it” works. The problem is
that “it” doesn’t just deal with “proceeding” and "associate"ing.
It also deals with grouping, arity, precedence, order of
evaluation, sequence points, agreement points, aliasing,
optimization and interleaving.

The significant of all this buzz’y stuff is that side-effects
can happen during many C (or C++) expressions. And often, they do!

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

31

Rick Lake <rwlake@spamfree.domain.invalid> wrote:

Well you’re not alone: I also was under that impression. Moreover, my
Watcom language reference (p.112) says:

quote
Note that, unlike most other operators, the assignment operators
associate from right to left. For example, the expression,

a += b = c

is translated as if it had been bracketed as follows:

a += (b = c)

end quote

If you think about it, it does make sense, since:

(a += b) = c

would mean trying to assign (the value of) c to an expression (a += b)
which does not yield an lvalue.

And the associativity does not mean anything more than that. It only
lets you tell which parts of the expression are the arguments of an
operator. It does not tell you that one of the arguments must be
calculated before the other one.

Consider an example that doesn’t even rely on associativity because it
has only one assignment operator in it:

*getaddress() = getvalue();

The arguments of the first “=” are “*getaddress()” (an lvalue) and
“getvalue()” (an rvalue). Both must be calculated before the assignment
can take place, but the compiler is free to decide whether to call
getaddress() before or after getvalue(). If the result of one depends
on any side-effects of the other, you’re in trouble.

For instance, imagine that the value of getaddress() depends on a
variable that getvalue() modifies:

void **getaddress() { return &fred_p->b; }
void *getvalue() { return ( fred_p = &fred ); }

Now look what happens if you inline these functions into our assignment
expression:

  • & fred_p->b = ( fred_p = &fred );

and then remove the unnecessary parentheses (the associativity is what
tells us that they’re unnecessary!) and the superfluous “*&”:

fred_p->b = fred_p = &fred;

We ended up with something pretty similar to the original example!


\

Wojtek Lerch QNX Software Systems Ltd.

32

Wojtek Lerch <wojtek_l@yahoo.ca> wrote:

Rick Lake <> rwlake@spamfree.domain.invalid> > wrote:
Well you’re not alone: I also was under that impression. Moreover, my
Watcom language reference (p.112) says:

quote
Note that, unlike most other operators, the assignment operators
associate from right to left. For example, the expression,

a += b = c

is translated as if it had been bracketed as follows:

a += (b = c)

end quote

If you think about it, it does make sense, since:

(a += b) = c

would mean trying to assign (the value of) c to an expression (a += b)
which does not yield an lvalue.

And the associativity does not mean anything more than that. It only
lets you tell which parts of the expression are the arguments of an
operator. It does not tell you that one of the arguments must be
calculated before the other one.

yes, yes, I agree with you all the way :slight_smile: [see my previous post in this
thread. I was mislead, because I read someone else’s post out of context.]
my faith is completely restored :slight_smile:

Consider an example that doesn’t even rely on associativity because it
has only one assignment operator in it:

*getaddress() = getvalue();

The arguments of the first “=” are “*getaddress()” (an lvalue) and
“getvalue()” (an rvalue). Both must be calculated before the assignment
can take place, but the compiler is free to decide whether to call
getaddress() before or after getvalue(). If the result of one depends
on any side-effects of the other, you’re in trouble.

For instance, imagine that the value of getaddress() depends on a
variable that getvalue() modifies:

void **getaddress() { return &fred_p->b; }
void *getvalue() { return ( fred_p = &fred ); }

Now look what happens if you inline these functions into our assignment
expression:

  • & fred_p->b = ( fred_p = &fred );

and then remove the unnecessary parentheses (the associativity is what
tells us that they’re unnecessary!) and the superfluous “*&”:

fred_p->b = fred_p = &fred;

We ended up with something pretty similar to the original example!

exactly; eventually it all boils down to unpredictable side-effects during
expression evaluation because of unpredictable evaluation order. (nice
proof, btw…)

–
Wojtek Lerch QNX Software Systems Ltd.

regards,
rick

33

Rick Lake <rwlake@spamfree.domain.invalid> wrote:

Wojtek Lerch <> wojtek_l@yahoo.ca> > wrote:
…
*getaddress() = getvalue();

The arguments of the first “=” are “*getaddress()” (an lvalue) and
“getvalue()” (an rvalue). Both must be calculated before the assignment
can take place, but the compiler is free to decide whether to call
getaddress() before or after getvalue(). If the result of one depends
on any side-effects of the other, you’re in trouble.

For instance, imagine that the value of getaddress() depends on a
variable that getvalue() modifies:

void **getaddress() { return &fred_p->b; }
void *getvalue() { return ( fred_p = &fred ); }

Now look what happens if you inline these functions into our assignment
expression:
…
fred_p->b = fred_p = &fred;

We ended up with something pretty similar to the original example!

exactly; eventually it all boils down to unpredictable side-effects during
expression evaluation because of unpredictable evaluation order. (nice
proof, btw…)

Thank you.

Actually, I cheated a bit. :slight_smile:

In the example with two function calls, the C standard only says the
order is “unspecified”; but the two functions will be called. If fred_p
is initialized to a valid non-NULL value, the code is legal and must
have one of the two possible results.

But inlining the function calls makes some sequence points disappear,
which changes the outcome from “unspecified” to “undefined”. In this
case, the compiler is allowed to scramble your code completely, and even
if it ends up formatting your hard drive (or causing your OS to hang),
it’s your fault, not the compiler’s.

In practice, you don’t care about this kind of distinction: you just
consider both cases to be broken code.

–
Wojtek Lerch QNX Software Systems Ltd.

34

Thanks a lot to Greg Comeau and Wojtech Lerch for their expert
commentary on the “a=b=c” type of C statement. Now, where would a
journeyman programmer go to learn more about the C standard and terms
like sequence points and arity. I work mainly from the K&R 2nd
edition ( (c) 1988 ) and Harbison and Steele’s “C, A Reference
Manual.”

On 5 Sep 2001 21:43:18 GMT, “Rick Lake”
<rwlake@spamfree.domain.invalid> wrote:

Well you’re not alone: I also was under that impression. Moreover, my
Watcom language reference (p.112) says:

quote
Note that, unlike most other operators, the assignment operators
associate from right to left. For example, the expression,

a += b = c

is translated as if it had been bracketed as follows:

a += (b = c)

end quote

If you think about it, it does make sense, since:

(a += b) = c

would mean trying to assign (the value of) c to an expression (a += b)
which does not yield an lvalue.

But then again, my lang.ref. manual may be outdated. Besides, a compiler
implementation does not prove the standard.

regards,
rick

Dean Douthat <> ddouthat@faac.com> > wrote:
I have been under the mistaken belief since, I guess, about 1976 that
assignments proceeded from right to left in order. I wonder if that was
true once (ante-ANSI) or did I just dream it up?

Thanks for correcting my misunderstanding.

Dean

Josh Hamacher wrote:

Just for the record, I didn’t write that code; I’m porting an existing
app, and that code was already in it. I don’t much care for that style,
either, to tell you the truth.

I did, however, think that it was legal C++ (for the same reason as
Bill; I thought the assignment operator was always evaluated
right-to-left). Thanks for enlightening me.

Josh Hamacher
FAAC Incorporated

Bob Bottemiller
Stein.DSI/Redmond, WA USA

35

Bob Bottemiller <bob.bottemiller@fmcti.com> wrote:

Thanks a lot to Greg Comeau and Wojtech Lerch for their expert
commentary on the “a=b=c” type of C statement. Now, where would a
journeyman programmer go to learn more about the C standard and terms
like sequence points and arity. I work mainly from the K&R 2nd
edition ( (c) 1988 ) and Harbison and Steele’s “C, A Reference
Manual.”

You can download a copy of the latest Standard from ANSI for only $18 US:

http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI%2FISO%2FIEC+9899-1999


\

Wojtek Lerch QNX Software Systems Ltd.

36

“Phil Olynyk” <pholynyk@home.com> wrote in message
news:3B96D1BE.6F0E4C62@home.com…

I’d be curious to read the discussions in ANSI about why this was changed
to be
ambiguous, as it now is, apparently…

Me too. Go get them on the phone.

37

In article <3b9798ed.1617738@inn.qnx.com>,
Bob Bottemiller <bob.bottemiller@fmcti.com> wrote:

Thanks a lot to Greg Comeau and Wojtech Lerch for their expert
commentary on the “a=b=c” type of C statement. Now, where would a
journeyman programmer go to learn more about the C standard and terms
like sequence points and arity. I work mainly from the K&R 2nd
edition ( (c) 1988 ) and Harbison and Steele’s “C, A Reference
Manual.”

Arity is a minor issue and deals with the number of arguments
to a function. You probably won’t see this discussed anywhere per se
(either by that term, or at all). But things like sequence points
should be in both the books that you mention above. In fact,
I seem to recall both books that you mention above each have
a chapter about expression evaluation issues (and so I would
expect would list “sequence point” in their respective index. No?

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

38

“Wojtek Lerch” <wojtek_l@yahoo.ca> wrote in message
news:9n816f$knc$1@nntp.qnx.com…

But inlining the function calls makes some sequence points disappear,
which changes the outcome from “unspecified” to “undefined”. In this
case, the compiler is allowed to scramble your code completely, and even
if it ends up formatting your hard drive (or causing your OS to hang),
it’s your fault, not the compiler’s.

Say Wojtek, can you tell me what compiler will re-format my hard drive. I

want to move that to the very bottom of my “Must Buy” list. ;~}

But I do get your, rather extream, example.

39

“Bill Caroselli (Q-TPS)” <qtps@earthlink.net> wrote:

“Wojtek Lerch” <> wojtek_l@yahoo.ca> > wrote in message
news:9n816f$knc$> 1@nntp.qnx.com> …
But inlining the function calls makes some sequence points disappear,
which changes the outcome from “unspecified” to “undefined”. In this
case, the compiler is allowed to scramble your code completely, and even
if it ends up formatting your hard drive (or causing your OS to hang),
it’s your fault, not the compiler’s.

Say Wojtek, can you tell me what compiler will re-format my hard drive. I
want to move that to the very bottom of my “Must Buy” list. ;~}

I don’t know of one that has done that, but that doesn’t prove anything.

But think about this: in some cases of “undefined behaviour”, you might
end up overwriting a string with random garbage from unitialized memory.
What if it’s a string that you’re about to pass to system()?

But the less extreme example of causing your OS to hang is real. Guess
what OS that was…

–
Wojtek Lerch QNX Software Systems Ltd.

40

Yes, I have tried to read this and POSIX but it seems you need to be a language lawyer
and/or compiler writer to make sense of much of this stuff. I’m asking those whose job it
is to parse these standards to warn against dangerous/undefined constructs. Perhaps a
“Bitchin’ Betty” lint is in order or a lint mode for compilers.

Wojtek Lerch wrote:

Bob Bottemiller <> bob.bottemiller@fmcti.com> > wrote:
Thanks a lot to Greg Comeau and Wojtech Lerch for their expert
commentary on the “a=b=c” type of C statement. Now, where would a
journeyman programmer go to learn more about the C standard and terms
like sequence points and arity. I work mainly from the K&R 2nd
edition ( (c) 1988 ) and Harbison and Steele’s “C, A Reference
Manual.”

You can download a copy of the latest Standard from ANSI for only $18 US:

http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI%2FISO%2FIEC+9899-1999

–
Wojtek Lerch QNX Software Systems Ltd.