Re: [Edoc-main] Skip throw() function pointers?

[Brendon C. <bc...@av...>]

Niko Ritari wrote:
> On Tue, 2007-11-27 at 08:25 +1100, Brendon Costa wrote: 
>> The warnings/errors I thought MIGHT be affected specifically relate to
>> situations where the currently caught exception is re-thrown from a
>> called function. This should emit a warning anyway for exception type
>> "..." being thrown from a no-throw function. An example follows:
> 
> Obviously this is something I never thought about. To be honest, I
> didn't know it was even possible. If this is important enough, perhaps
> functions that re-throw outside a catch block could be detected and
> always expanded, throw() or not.
> 

Neither did I until a long way through writing the code for EDoc++ and
I looked more at how GCC implements exception handling.

> Would you care to explain briefly how EDoc++ currently handles these
> situations? I don't see how it can sensibly process a function with a
> naked "throw;" without knowing the context it's called in (especially
> since there may be multiple potential callers), or does it somehow
> descend to such functions from each caller unlike its normal behaviour
> of only processing each function without circular dependencies once?

EDoc++ has a special exception type "..." which represents a rethrow
exception. This may then be expanded by a calling function when it
asks the function being called for its lists of exceptions.

The exact algorithm is more detailed than the above explanation as you
would probably expect. But in essence the algorithm is the same as
would normally be used to handle a rethrow that is directly inside a
catch block, its just that we handle this across function boundaries
and use a exception type ... as a place holder.

I am reasonably sure that the current implementation works fine. There
are a number of automated tests to check this particular problem. I
initially found the issue i think by trying to compile libstdc++ which
seems to make use of the feature (But my memory is a bit fuzzy on this).


> I was thinking about this, even though I'm not currently interested in
> trying to implement anything myself. This seems like a somewhat
> complicated instance of a common problem encountered for example in data
> flow analysis in compilers, and infinitely more information can be found
> elsewhere. By taking a sort of reverse approach, an accurate result
> should be attainable with efficiency. The algorithm would be "pushing"
> exceptions to calling functions, instead of "pulling" them from called
> functions.
> 

I have not looked in detail at your proposal to determine if it would
work or not for EDoc++, though thanks for the info. I have to admit i
did not think of doing it the way you described before so it may prove
fruitful.

For the moment it is infeasible to change the current implementation
as from what i can see it would require a reasonably large
modification. But I will look into it after a few things on my current
list to be done before version 1.0.0 have been completed.


> I'm not sure about the current algorithm, but given your results in
> another message, it seems to be exponential on C. Even a naive
> implementation that doesn't keep track of exceptions "seen" at
> call-points should easily beat it, at least with a large circular part
> of the call-graph.

The current algorithm is slow for the circular case. I think that its
efficiency for the non-circular case is currently acceptable though
from my brief reading of your description of the other method it could
be improved.

With the union update i mentioned before it will make the circular
case of the same order as that for the current non-circular case.


> I'm sure there's quite a bit of code required to implement, let alone
> optimize, this algorithm in EDoc++. Maybe too much considering the
> problem that it solves. Or maybe there's something fundamental stopping
> this from being viable at all. At least the above discussed case of
> functions with naked "throw;"s may require special treatment.
> 
> Hope you got something out of this even if you aren't going to try to
> implement the algorithm. The explanation sure turned out longer than I
> thought...
> 
I appreciate the ideas. When i have a chance I will look more into how
I might be able to use it to improve EDoc++. Honestly that wont be at
least until mid next year though. I want to improve the integration of
EDoc++ with GCC and doxygen before I do any large changes to the base
EDoc++ application code.

I am however interested in making EDoc++ as useful a tool as possible.
This i think will include more in the way of speed optimizations for
the future which may include that algorithm you described.

Thanks for the info,
Brendon.

P.S. I should be able to get around to making a patch for the circular
call graph using unions before or just after Christmas.