> -----Original Message-----
> From: Worley, Dale (BL60:9D30)
> Sent: Friday, October 24, 2008 2:03 PM
> To: Beeton, Carolyn (CAR:9D60)
> Cc: [EMAIL PROTECTED]
> Subject: RE: [sipX-dev] Please review stdout/stderr intercept
> patchonXECS-1423
>
> 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.
ok. I'll test for that and fix it up.
>
> > > 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
>
>
ah yes missed the second parameter.
I HATE string manipulation!
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
