Re: [boost] Patch for the Function library

From: Guillaume Melquiond (gmelquio_at_[hidden])
Date: 2003-05-19 06:45:27

On Mon, 19 May 2003, Giovanni Bajo wrote:

> Guillaume Melquiond <gmelquio_at_[hidden]> wrote:

> > My interpretation of the standard was: an allocation function that returns
> > a null pointer must have an empty exception clause and so is not allowed
> > to throw any kind of exception.
>
> You are reading it backward. It says that an allocation function declared as
> throw() must return a null pointer. It does not say "*only* allocation
> functions declared as throw()", nor it says "any other allocation function
> must not return 0". In other words this is only an "if" clause, not a "if
> and only if".

It does (!) say that "any other allocation function must not return 0".

First, the previous paragraph (3.7.3.1-2) says that a successful
allocation cannot return a null pointer, even if the size of the object is
zero. So an allocator that returns a null pointer can only mean the
allocation failed, right?

Next, the Standard says "If an allocation function declared with an empty
exception-specification [snip]. Any other allocation function [so they are
speaking about functions that do not have an empty exception-
specification] that fails to allocate storage shall only indicate failure
by throwing an exception of class [snip]".

Consequently, functions that do not have an empty exception-specification
cannot return a null pointer when they are successful (since a null
pointer is not allowed in case of success) and they cannot return a null
pointer whey they fail (since a failure need to be indicated "by throwing
an exception" for "any other allocation function"). And unless I'm missing
something, an allocation can only be successful or not successful; there
is no third state where the allocator could return a null pointer.

So, where is the defect in this reasoning? Do you still think I'm reading
it backward? When there is an "if A, then B" clause and an "if not A, then
not B" clause, it is possible to deduce an "A if and only if B" clause.

> >> Since this allocation function is not declared throw(), it should throw a
> >> std::bad_alloc(), not a runtime_error(). The return value does not make
> >> sense here because of the throw: that statement is never reached. If
> there
>
> > What kind of argument is that? :-)
>
> Probably I wasn't clear. What I'm saying is that it would be silly for the
> standard to set rules for the return value of a function in a condition in
> which it is supposed to throw an exception. If it said "please, make it
> throw, and then return anything but zero", one would wonder why there should
> be a rule about the return value when the function is not supposed to return
> (at least in that code path).

I think it's more ideological than anything alse at this point. I like
that my compiler tries to find errors even in unreachable code. You don't
seem to share this point of view. And the Standard doesn't say anything at
all about that, does it? So it's better to drop this part of the
discussion, it would be better suited for the c++ newsgroup imho.

But there is still the issue of the return statement. And it does concern
this mailing-list.

> > Yes the code is unreachable; but it's not enough of a reason to write bad
> > code each time it's unreachable.
>
> But do you really think that there can be a rule set by the standard for a
> situation which will never happen?
> And there is more: if I run the code with Comeau, I get a warning saying
> that "return 0" is unreachable. So I could submit a patch to remove it
> because it breaks my -Werror compilation on Comeau. It does not make sense
> for the standard to prescribe such a return value, and a return statement
> just to shut down an incorrect warning like this one should be activated
> only for compilers suffering from this behaviour.

Yes, I completely agree. It's the reason why I would have simply removed
the return statement if it was only my decision. But since the maintainer
of the file already had decided to put this statement to suppress some
warnings, I wanted to modify it so that this already faulty code does
annoy one less compiler (GCC) than it is already annoying (Comeau and
Borland).

The best solution would be to track down compilers that complains if the
return statement is missing and conditionaly add it for them. But only the
maintainer can tell us for which compiler the dummy return statement was
needed. Or maybe we could just remove it and see which compilers suddenly
complains in the regression tests :-).

> > The return statement is already here to suppress warnings with some
> > compilers. But it also adds a warning with GCC. It's the reason why I
> > suggested a patch that does a minimal change of the code: the return
> > statement is not suppressed, but the return value is changed.
>
> Yes I understand your patch, but I strongly believe that it is GCC in fault
> here, not the code. If there is a fault in the code at all, it is that it's
> throwing a runtime_error instead of a bad_alloc as the standard prescribes.
>
> >> are warnings about the return value, compilers could be improved to at
> >> least shut them off in such situation, or can be simply turned off in any
> >> way (return 0 is ok).
> >>
> >> What is the warning you get with GCC?
> >
> > GCC complains that the allocator returns a null pointer and so should have
> > an empty throw() clause.
>
> I see the warning now. I'm forwarding this message to Gabriel Dos Reis,
> which is also the GCC diagnostic mantainer. Maybe he can shed some lights on
> this issue.
>
> Giovanni Bajo

Regards,

Guillaume