[Issue 17250] ProcessPipes (std.process) should provide a test for a null pid

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Mon Jul 17 12:23:21 PDT 2017


https://issues.dlang.org/show_bug.cgi?id=17250

--- Comment #5 from Jon Degenhardt <jrdemail2000-dlang at yahoo.com> ---
(In reply to Vladimir Panteleev from comment #4)
> (In reply to Jon Degenhardt from comment #1)
> > The problem is that there is no method available to determine if pid is null
> > prior to call the pid() method.
> 
> Why not: if (pipes !is ProcessPipes.init)

Isn't 'is' a compile-time expression? The test needs to be run-time. Though
that would mean 'if (pipes != ProcessPipes.init)' would work. Either way, these
seem like very obscure ways to do such a test.

> 
> (In reply to RazvanN from comment #2)
> > I think the solution here is to remove the assert and expect the user to
> > check if the result of pid is null.
> 
> I think that's OK too, though it has the small downside that null
> dereferencing bugs are harder to diagnose on non-Windows systems.
> 
> We could also add an implicit conversion to bool.

Implicit conversion to bool sounds pretty good. Then it'd become:

    scope(exit) if (pipes) wait(pipes.pid)

For me the downside of simply removing the assert and returning a null Pid
object is that it uses an internal implementation detail of ProcessPipes to
describe the state of the ProcessPipes instance. Modularity is better served by
separating the ProcessPipes state from the state internal _pid member, at least
in the ProcessPipes API. (This argument also says the original suggested API
name of 'isNullPid' is not a good name.)

--


More information about the Digitalmars-d-bugs mailing list