🚀 go-pugleaf

James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:


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

[ ... ] 
>|> 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.

Okay, so your position is that even undefined behavior will rarely if
ever do anything really awful, and if it does it'll only be by accident.

I guess a lot of the importance of this depends on what your program is
doing.  For instance it's not particularly out of line for the program
to simply get stopped dead with some error like:
	SYSDIV0 Errror.  Program stopped.
Now depending on the program in question, that often won't be
particularly terrible - it might simply mean restarting an editor or
somesuch.  OTOH, in a system that controlled, say, the sewage system for
an entire city, simply stopping is grossly unacceptable behavior, and
might be a much greater disaster than formatting the average hard disk.
(I happen to choose this example largely because it's a job I worked at
for a few years.)

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

I think they're frequently significant -- certainly if I add three
numbers together and I know their range will prevent an overflow, I know
the order of evaluation is unspecified, but it certainly shouldn't
require _anything_ on my part to ensure against _anything_ strange
happening -- the overall results of the action are clearly and well
defined no matter what.  The change can produce a slight error, but
nothing more.

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

This reminds me - I've been meaning to ask.  The DWP makes it clear that
the struct hack can't be depended upon with anything but a POD, but does
it actually make it defined for a POD, or does it leave it undefined,
and simply make clear that it'll never work otherwise?

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

I'll certainly agree with that.  For one thing, the C and C++ stanards
are from from the only ones around.  For quite a bit of code, POSIX may
be a more useful standard overall, and even though `far' is legally in
the user's name space, you're certainly right that ignoring a huge
market (regardless of one's personal feelings toward it) can be a a
foolish decision.
    Later,
    Jerry.

/* I can barely express my own opinions; I certainly can't
 * express anybody else's.
 *
 * The universe is a figment of its own imagination.
 */



---
[ 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. ]