Memory management allocation design

[Eric.VanAlst@…]

In PSLib SRS paragraph 3.2.1.5, constructors shall never return NULL and
functions which call constructors do not need to check the return value. What
would be the proper action if for example psVectorAlloc is passed an invalid
argument for size or element type? If the constructor doesn't understand what
is to be constructed based on a user input, what should it do and how does it
convey this information back to the user?

[eugene]

this is definitely an issue I'd like to discuss in our next tuesday meeting
(this morning). Our current design philosophy seems rather restricted, and it
is probably not so much of a burden to type:

if ((V = psAlloc(N)) == NULL) {

psAbort ("failed to get it");

}

(if we allowed if's without {} and in-line statements, it could be:

if ((V = psAlloc(N)) == NULL) { psAbort ("failed to get it"); }

it seems to be more necessary with richer alloc/free functions

[eugene]

we've decided that the Alloc functions will call psAbort on an error. this
means it is the responsibility of the calling functions to validate the input
parameters if they want to recover from an error (or trap sig abort - not the
advised method).

This means we should look for places where boilerplate range checking code can
be replaced with range-checking functions associated with specific variable types.