svn 14566

[Mihai Buha]

> From: Rob Landley [mailto:rob at landley.net] 
> On Monday 20 March 2006 2:51 am, Mihai Buha wrote:
> > > From: Rob Landley
> > > Does changing the order really making a difference?  Are you
> > > saying that "if
> > > (x=5 && 0)" _won't_ optimize out?  (If the first thing is a
> > > function call
> > > that might have a side effect, I could see it.  But x && 0
> > > not optimizing out
> > > is a bug in the compiler.  Have you actually _seen_ this bug?
> >
> > Not sure if this bug has been seen. I didn't even looked up
> > svn 14566. But to call "buggy" a compiler that simply follows the
> > operator associativity rules as set by the C standard, looks to
> > me like an exaggeration...
> 
> x==5 && 0 is a constant 0.
> 
> 0 && x==5 is a constant 0.
> 
> How does that involve operator associativity rules?  If x==5 
> becomes a 
> statement whose result is discarded, then the statement may 
> be discarded 
> unless it has side effects, which the compiler can trivially 
> tell it doesn't.

There is a difference between "a compiler can tell" and "a
compiler must tell", or even "a compiler should tell". Your
statement that "[it] is a bug in the compiler" implies that the
compiler is required to see whether there are side effects and,
in case there are none, to optimize the expression. I agree that
in the case of an optimizing compiler your statement may be true,
I also agree that most of the current compilers may do some sort
of optimizations, but I don't agree that the code should be
written on the assumption that "the compiler would optimize
this anyway". This is the reason why I prefer ++i instead of
i++.

> You do realise that by sending this to a public list, you 
> basically mean that 
> it doesn't apply _anywhere_, right?  (If it ever gets to 
> court the defense is 
> "They stick exactly the same notice on things they post over 
> public urinals, 
> how the heck am I supposed to know in which context they do 
> and don't mean 
> it?")

I do. But you also do realize that people in the management
can decide that the chief sysadmin sticks some sort of notice
after each of the mails which leave the network, and that I
or any other co-worker of mine can do nothing about it,
because that happens at the MTA level, not at the MUA level.

If you are interested, I did complain to the local sysadmin
about both the existence of the "disclaimer" and also about
it being written on a single line many characters long, and
I did that yesterday, as soon as I saw my mail in the busybox
archive. The answer was "the big guy was told to do it" and,
respectively, "I will tell him about that issue". Given that,
I believe you should either silently delete the offending
text, or state in the mailing list rules that "people who
work in companies who do that should not send us mail".

> Rob
Mihai

Any text below the following line is beyond my control and
bears no resemblance to my ideas and thoughts.
----Line----Line----Line----Line----Line----Line----
This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments.