In article <5sje86$6c6@mulga.cs.mu.OZ.AU>, fjh@mundook.cs.mu.OZ.AU (Fergus
Henderson) wrote:

> >The particular situation I've run into is this sort of thing:
> >
> >    int foo() {
> >      try {
> >        do_something();
> >        if (something_went_wrong)
> >          throw an_exception;
> >        else
> >          return 1;
> >      }
> >      catch (...) {
> >        do_something_else();
> >        throw;
> >      }
> >    }
> >
> >Some compilers accept this as a perfectly legal funcion, which (as far
> >as I can see) it is: there's no way the flow of control can fall off the
> >end. But at least one (Symantec 7.5) complains (fatal error, not just
> >warning) about the lack of a return ("implied return of foo at closing
> >'}' does not return value").
>
>If that is indeed the case, then Symantec 7.5 is not conforming.

  The current Symantec 7.5r8 MacOS indeed has exception bugs, one is that
one cannot replace "return" with "throw", especially in
    T f() { throw U(); }
and similar situations: The complaint is that there is no return. So one
can write
    T f() { throw U(); return T(); }
and the compiler swallows it, even execution never gets to the "return"
part. (In addition, wild use of exceptions may cause internal errors. --
But that discussion does not belong in this group.)

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

Hans Aberg <haberg@matematik.su.se> writes:

> In article <5sje86$6c6@mulga.cs.mu.OZ.AU>, fjh@mundook.cs.mu.OZ.AU (Fergus
> Henderson) wrote:
>
> > >The particular situation I've run into is this sort of thing:

[ A function which never fails to return a value ]

> > >Some compilers accept this as a perfectly legal funcion, which (as far
> > >as I can see) it is: there's no way the flow of control can fall off the
> > >end. But at least one (Symantec 7.5) complains (fatal error, not just
> > >warning) about the lack of a return ("implied return of foo at closing
> > >'}' does not return value").
> >
> >If that is indeed the case, then Symantec 7.5 is not conforming.

Yes

>   The current Symantec 7.5r8 MacOS indeed has exception bugs, one is that
> one cannot replace "return" with "throw", especially in

T f() { }

is well-formed. If Symantec 7.5 doesn't accept that in the ANSI mode
then it isn't conforming (an ANSI mode might be some option on and
warnings are errors off).

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ 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
]

Just how smart is a compiler required to be about functions with unusual
return behaviour?

I'm under the impression that the draft standard requires a conforming
compiler to accept all legal programs (it can give whatever warnings it
likes, but it can't refuse to compile). A function that actually (not
just potentially) flows off the end without returning invokes undefined
behaviour [stmt.return], and of course most compilers will spot obvious
examples and report a fatal error.

But it's not always obvious whether a function actually can fall off the
end without returning (trying to determine this in the general case is
equivalent to the halting problem), and I would have expected that a
compiler that can't resolve a particular case one way or the other would
therefore be required to give the program the benefit of the doubt
(otherwise it risks wrongly rejecting a legal program).

The particular situation I've run into is this sort of thing:

    int foo() {
      try {
        do_something();
        if (something_went_wrong)
          throw an_exception;
        else
          return 1;
      }
      catch (...) {
        do_something_else();
        throw;
      }
    }

Some compilers accept this as a perfectly legal funcion, which (as far
as I can see) it is: there's no way the flow of control can fall off the
end. But at least one (Symantec 7.5) complains (fatal error, not just
warning) about the lack of a return ("implied return of foo at closing
'}' does not return value").

Is this compiler in violation of the standard, or is this a quality of
implementation issue? I think it's a violation (as argued above), but
I'd like to hear the opinions of the experts.

(Actually, it's just occurred to me that, strictly speaking, compilers
shouldn't treat even obvious fall-off-the-end cases as fatal errors.
After all, it's not undefined behaviour until flow of control *actually
does* fall off the end, and when the program is run, the function might
never get called. But this is probably the kind of reasoning that
inspired the line quoted below... :-) )

--
Ross Smith ............................. <mailto:ross.smith@nz.eds.com>
Internet and New Media, EDS (New Zealand) Ltd., Wellington, New Zealand
   "The first thing we do, let's kill all the language lawyers."
                             -- Henry VI Part II, by W. Shakespeare;
                                additional dialogue by B. Stroustrup
---
[ 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
]

Ross Smith <ross.smith@nz.eds.com> writes:

 >I'm under the impression that the draft standard requires a conforming
 >compiler to accept all legal programs (it can give whatever warnings it
 >likes, but it can't refuse to compile).

Correct.

 >A function that actually (not
 >just potentially) flows off the end without returning invokes undefined
 >behaviour [stmt.return], and of course most compilers will spot obvious
 >examples and report a fatal error.
 >
 >But it's not always obvious whether a function actually can fall off the
 >end without returning (trying to determine this in the general case is
 >equivalent to the halting problem), and I would have expected that a
 >compiler that can't resolve a particular case one way or the other would
 >therefore be required to give the program the benefit of the doubt
 >(otherwise it risks wrongly rejecting a legal program).

Your expectation is correct.

 >The particular situation I've run into is this sort of thing:
 >
 >    int foo() {
 >      try {
 >        do_something();
 >        if (something_went_wrong)
 >          throw an_exception;
 >        else
 >          return 1;
 >      }
 >      catch (...) {
 >        do_something_else();
 >        throw;
 >      }
 >    }
 >
 >Some compilers accept this as a perfectly legal funcion, which (as far
 >as I can see) it is: there's no way the flow of control can fall off the
 >end. But at least one (Symantec 7.5) complains (fatal error, not just
 >warning) about the lack of a return ("implied return of foo at closing
 >'}' does not return value").

If that is indeed the case, then Symantec 7.5 is not conforming.

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