Vote for std.process

Manu turkeyman at gmail.com
Fri Apr 12 00:04:08 PDT 2013


On 12 April 2013 14:46, Jesse Phillips <Jessekphillips+d at gmail.com> wrote:

> It is that time, If you would like to see the proposed std.process include
> into Phobos please vote yes. If one condition must be met specify under
> what condition, otherwise vote no.
>

I didn't think I had much of an opinion on std.process, but I just gave it
a quick once over and noticed, relating to our recent discussions about
flagrant GC usage throughout phobos, that this is riddled with the exact
sorts of issues I've been talking about:

string[string] is used in the main API to receive environment variables;
perhaps kinda convenient, but it's impossible to supply environment
variables with loads of allocations.

toStringz is used liberally; alternatively, alloca() could allocate the
c-string's on the stack and zero terminate them there, passing a pointer to
the stack string to the OS functions.

String concatenation is rampant! Look at this code to parse the env
variables (which are already an AA):

    foreach (var, val; childEnv)
        envz[pos++] = (var~'='~val~'\0').ptr;


And many many more of the same...

This is a lib that spawns a process, I can't imagine why this library
should need to allocate a single byte, but it allocates wildly just to
perform a trivial pass-through to the OS.
This module is no exception either, basically all of phobos is like this,
and I'd like to see careful consideration made to these details in the
future.

I've said before, I sadly have to avoid phobos like the plague. Some
modules (like this one) that provide fundamental functionality - not just
helper functions - can't be avoided. Requirements for those should be extra
strict in my opinion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130412/25b43600/attachment.html>


More information about the Digitalmars-d mailing list