On Wed, Feb 06, 2019 at 10:15:27AM -0700, Martin Sebor wrote:
> > > -For C++, a function without return type always produces a diagnostic
> > > -message, even when @option{-Wno-return-type} is specified. The only
> > > -exceptions are @code{main} and functions defined in system headers.
> > > +For C++, calling a non-@code{void} function other than @code{main} that
> > > flows
> > > +off the end is undefined even if the value of the function is not used.
> >
> > That is not true, the undefined behavior is not when calling such a
> > function,
> > but only when it flows off the end. So, it is perfectly fine if you have:
> > int
> > foo (int x)
> > {
> > if (x > 10)
> > return 20;
> > }
> > and you only ever call foo with x > 10, or if you have:
> > int
> > bar ()
> > {
> > baz ();
> > }
> > and baz always throws, or never returns etc. So, if we try to clarify, we
> > should clarify it correctly.
>
> Sigh. Was that jab really necessary?
>
> The C++ standard says:
>
> ...flowing off the end of a function other than main (6.6.1)
> results in undefined behavior.
>
> It doesn't mention anything about calling the function so it seems
> to me the text I added is no less correct or clear than that. I see
> no point in going into unlikely corner cases that the standard itself
> make provisions for.
Your new text talks about calling the function though, which might be read as
that
the UB is already when you call such a function. Why don't you use the
standard wording instead, i.e.
"For C++, flowing off the end of a function other than @code{main} is
undefined even if the return value from the function is not used in the
caller."
or similar?
Jakub
