🚀 go-pugleaf

In article <4a2nvl$nq@natasha.rmii.com> jcoffin@rmii.com (Jerry
Coffin) writes:

|> kanze@gabi-soft.fr (J. Kanze) wrote:

|> [ ... ] 

|> >I see what you and Steve Clamage are getting at, but strictly speaking,
|> >from a standards point of view, is there any real difference?  If I
|> >understand you correctly, unspecified means that it will work, but the
|> >standard does not define what `work' means in this context.  So if it
|> >formats my hard disk (to take the classical example), the vendor can
|> >simply say: it's not a bug, that's our definition of work.

|> Not really.  Consider a real example of unspecified behavior:

|> 	a = b + c + d;

|> Now, it is unspecified whether the multiplication will be evaluated
|> before or after the division.  Under some circumstances, you may even be
|> able to detect a diference.  (e.g. depending on the magnitudes involved,
|> floating point accuracy can be affected.)

|> Now assuming the magnitudes involved are such that no intermediate
|> result can cause an overflow, then this can't do anything other than
|> give us a result.  Changes in evaluation order may change the accuracy
|> of the result, but certainly can't reformat your hard disk.  By
|> contrast, if we compute `b*c/d' and d is 0, then the result is
|> undefined, and something terrible may happen.

I agree with what you are saying, but you missed the point of my
statement.  No compiler is going to intentionally generate code to
format the hard disk just because you dared to write a program which
invoked undefined behavior.  So *practically*, dividing by 0 will not
format your hard disk; if it did, I'd certainly complain to the vendor
(and maybe even sue him, if I could prove that he did it
intentionally), even though he is formally conformant.

On the other hand, suppose that due to an error in the OS, a floating
point exception actually did format the hard disk.  If the floating
point exception occurs because I divided by zero, it's my fault, but
if it occurs because the compiler illegally reordered an expression
(thus causing overflow), it's the compilers fault.  In both cases,
however, my data is gone.

Within the standard, such distinctions are necessary, because they
tell the compiler implementor which cases he must verify, and where he
can pretend that the programmer knows what he is doing.  For the
typical user, however, they really aren't that significant.

Another example of what I am getting at: the C standard declares the
infamous struct hack undefined behavior.  In fact, however, it is
widespread in existing code, and I imagine that it also occurs in new
code relatively frequently.  The result, of course, is that no one
implements a C compiler where it doesn't work, at least with certain
modes of compile.

In the other direction, it is perfectly legal to have a global
function called read and a variable called far in your (C) code.  I
wouldn't do it, at least unless I was 100% sure of all the platforms
my code would ever run on.

This is not to belittle the importance of a standard.  In C++, we need
one desparately.  But in real life, the standard is just one of the
parameters that you have to consider.

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]