On Fri, 2008-10-24 at 13:20 -0400, Beeton, Carolyn (CAR:9D60) wrote:
> > 1. Is the capturing of stdout/stderr mandatory? Or can I use
> > OsProcess in a way that is like before? Does the default
> > behavior change?
>
> It is not mandatory that the app capture stdout/stderr, but I am going
> to remove the old way of redirecting it to a file. Default behaviour
> does not change, in that the app has to explicitly ask for output.
I can't quite tell from the patch, but it appears that the new code
*always* creates the pipes and sets stdout/stderr of the child to feed
the pipes, whereas the old code left stdout/stderr unchanged. If the
parent doesn't attempt to read the pipes and the child produces output,
the child will now stall. So the default behavior is now different.
> > 5. But I think we can omit placing a null at all using code like:
> >
> > printf("read %d bytes more: %.*s\n", rc, rc, buf);
> >
> > message.append(buf, rc);
>
> I'll try again, but I don't think it works without adding the nulls
> because if we return from the read with a full buffer, it won't be
> null-terminated and then append doesn't do the right thing. I test with
> the buffer size set very low so I can see what it does.
UtlString::append(char *, size_t) is the "pointer and length" form of
append; it does not require the input bytes to be ended with a NUL (and
it works even if the bytes contain a NUL).
But yes, a test would be extremely useful -- those sorts of loops are
vulnerable to errors.
Dale
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
