🚀 go-pugleaf

frigault@gla.ecoledoc.ibp.fr (Laurent FRIGAULT) writes:

>I discover a problem when trying to use a C++ reference to an object
>just before an ellipsis :

>int foo(const int& aInt,...){

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].
--
Steve Clamage, stephen.clamage@eng.sun.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                             ]

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

Is there any good reason why this has undefined behaviour rather than
being ill-formed code?  Surely this should be very easy for implementations
to detect and diagnose.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.


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

In article <4kr1p3$67g@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus
Henderson) writes:

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

|> Is there any good reason why this has undefined behaviour rather than
|> being ill-formed code?  Surely this should be very easy for implementations
|> to detect and diagnose.

Historical reasons, no doubt.  Declare the last parameter a char in C,
and you also get undefined behavior.

And it's surely no more difficult to diagnose a double underscore (and
at least one compiler does), which is also `undefined behavior'.
-- 
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.  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                             ]

In article <4kr1p3$67g@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus
Henderson) writes:

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

|> Is there any good reason why this has undefined behaviour rather than
|> being ill-formed code?  Surely this should be very easy for implementations
|> to detect and diagnose.

Hysterica^H^H^H^H^H^H^Horical reasons, no doubt.  Declare the last
parameter a char in C, and you also get undefined behavior.

And it's surely no more difficult to diagnose a double underscore (and
at least one compiler does), which is also `undefined behavior'.
-- 
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, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ 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                             ]

kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>|> 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].
>
>|> Is there any good reason why this has undefined behaviour rather than
>|> being ill-formed code?  Surely this should be very easy for
>|> implementations to detect and diagnose.
>
>Hysterica^H^H^H^H^H^H^Horical reasons, no doubt.  Declare the last
>parameter a char in C, and you also get undefined behavior.
>
>And it's surely no more difficult to diagnose a double underscore (and
>at least one compiler does), which is also `undefined behavior'.

No, I think providing useful diagnostics for use of references before
an elipsis is indeed less difficult than providing useful diagnostics
for use of double underscores.  It's difficult (though by no means
impossible, of course) for implementations to issue diagnostics for
uses of the implementation's part of the namespace without also issuing
diagnostics for definitions in the system header files or in code which
merely references macros defined in the system header files.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]

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