patch for command line arguments in activation

[Havoc Pennington]

On Sat, 2005-07-02 at 15:05 -0400, John (J5) Palmieri wrote:
>  You are going to get OOM in your test, your code just need
> to handle and propagate the error correctly.  This means that anytime
> you do an operation that may run out of memory (appending to string or
> list) you need to check the return value and handle the OOM which
> usually means just returning OOM from your function.

I would add a couple more detailed rules. If you get a malloc failure,
you should:

 - be sure all effects of the function are reverted; e.g. if you 
   did thing A, then failed, you need to undo thing A
   (because the caller will probably call your function again,
    for example. Or because "thing A" was a malloc and you need
    to free it to avoid a leak.)

 - if the function can fail for reasons other than OOM, be sure 
   to distinguish the OOM case from other failure reasons via 
   DBusError. If the function can only fail due to OOM, then 
   a bool return is fine, no need for DBusError

Basically think of each function as a transaction; on OOM, the
transaction atomically fails and the caller must be able to tell that it
failed due to OOM.

Havoc