🚀 go-pugleaf

>>|> clamage@Eng.Sun.COM (Steve Clamage) writes:
>>|> >According the draft standard, the results of using a reference
>>|> >type as the last pararmeter before the ellipsis (...) are
>>|> >undefined. See section 18.7 "Other runtime support" [lib.support.runtime].

Here we have a case where the user is relies on "undefined" behavior; the
user can easily fix the program not to do this; every compiler can detect it;
and some but not all compilers will generate surprising and undesirable
behavior.

In such circumstances, should the language standard require every
compiler to generate a diagnostic? I say yes, but I admit it's a matter
of taste. Those who disagree should note, however, that both C and
Fortran have a history of having to change a lot of their "no" answers
to "yes" answers the second time around: both ANSI C and Fortran 90 are
far stricter than their predecessors, because experienced programmers
seem to prefer to maximize the probability that their code will work
when ported to another place, rather than to take advantage of the
possibility that a few implementations might do something handy for the
"undefined" cases. In the case of Fortran 90, some of the pressure for
stricter diagnostics even came from implementors who were sick of
having to provide a "VMS" switch to implement undefined things the way
the Vax did, a "Cray" switch to implement undefined things the way the
Cray did, etc, so as to keep their users content. Members of the
committee should realize that in many cases, if the de jure standard
says "undefined" and doesn't require a diagnostic, the de facto
standard will be "implementors have to do whatever Microsoft does".
-- 
Steven Correll == PO Box 66625, Scotts Valley, CA 95067 == sjc@netcom.com


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]