List of Phobos functions that allocate memory?

Jonathan M Davis jmdavisProg at gmx.com
Fri Feb 7 17:25:17 PST 2014


On Friday, February 07, 2014 16:49:45 Andrei Alexandrescu wrote:
> On 2/7/14, 8:40 AM, Dmitry Olshansky wrote:
> > 07-Feb-2014 06:44, Walter Bright пишет:
> >> On 2/6/2014 2:15 PM, Brad Anderson wrote:
> >>> Personally I don't think bad user input qualifies as an exceptional
> >>> case because
> >>> it's expected to happen and the program is expected to handle it (and
> >>> let the
> >>> user know) when it does. That's just a matter of taste though.
> >> 
> >> It's not a matter of taste. If your input is subject to a DoS attack,
> >> don't put exceptions in the control flow.
> > 
> > Meh. If exceptions are such a liability we'd better make them (much)
> > faster.
> 
> One simple idea is to statically allocate the same exception and rethrow
> it over and over. After all there's no guarantee a distinct exception is
> thrown every time, and the approach is still memory safe (though it
> might surprise the programmer who saves a reference to an old exception).

As long as exceptions are cloneable, and people are aware of the fact that 
they tend to be non-unique, then it can be common practice to clone/dup an 
exception when you need to keep it around. However, the two potential problems 
with this overall approach are

1. Do we just always allocate one of each exception type per thread (probably 
in a static constructor for that exception type)? That would result in a fair 
number of exceptions being allocated up front. The obvious alternative would 
be to allocate it the first time that it's thrown so that you only end up with 
exceptions that get used being allocated, but regardless, we need to take 
close look at the allocation scheme.

2. This sort of thing has a definite impact on enforce and any idioms related 
to it. We'd need to either adjust enforce, enforceEx, etc. to avoid the 
allocation, or we'd need to introduce alternatives to them that expect 
something like a static opCall on the exception type which returns the common 
exception for that type or some other standard means of getting at the 
reusable exception.

Regardless, we need to agree upon a standard way to define exception types 
allow with some set of standard idioms for handling them such that we can deal 
with exceptions generically (particularly with regards to stuff like enforce) 
rather than it being an ad-hoc per-exception type thing that you can't 
reasonably rely on.

- Jonathan M Davis


More information about the Digitalmars-d mailing list