streams, stderr/out and zend_fprintf ?

Tips:

Don't use zend_printf.
Do try and use the php_stream_XXX API where it makes sense.

When running in a web environment, or without an ncurses interface, use
the PHP_WRITE() or php_printf() functions to generate output to send to
the browser; the output will be captured in the output buffering layer.

From what you've described, it sounds like you don't need to use the
streams API, so you are free to use the usual stdio approach, just
beware of the limitations of the solaris libc; if you are using the
pre-opened std* streams, you will be fine; if you need to open your own,
you might run out of luck.

Consider using POSIX open(), read(), write() rather than stdio. If you
miss printf and fprintf, you can open a php stream around an existing
file descriptor (with no more overhead than stdio) and use
php_stream_printf().

To access the std* streams via the streams API, you can open them using
the special php://stdin, php://stdout and php://stderr filenames. This
is, of course, not always a sensible thing to do in a web environment.

For more info, read the docs online at http://php.net/streams

--Wez.

I'm developing an extension that talks to a serial device (under RedHat 7.3).
The dynamic module will then be loaded into a CLI PHP, which will use an
ncurses interface, MySQL connectivity, etc. to make the application complete.

In light of recent talk about streams in extensions, I have a couple of
questions (I haven't done much extension programming yet, so forgive any
naiveness and hopefully I haven't missed anything in the mail archives):

-- With most console C programs I use the builtin stdin/stdout/stderr macros
with functions like fprintf. As a PHP extension, should I still be using
these, or does php_streams implement something different (ie, a php_stderr
macro)?

-- I'm seeing there is a zend_printf() but no zend_fprintf(). Am I missing
something, or should I just be using the standard C lib functions?

-- Should I be using php_stream_* functions to explicitly open the standard
I/O streams? Please say no.

For the extension I'm developing now, I can see how much of this is
irrelevant; it's a CLI based application, and when the process ends, so will
everything else, thanks to the kernel. However, I would like to design the
extension so that if I were to load it into an Apache DSO PHP, it'd be
working "the right way" and utilize all that's modern PHP extension
development (yes, I would have a reason to talk a serial device protocol from
a web server :)

Any pointers on these types of best practices would be greatly appreciated.

Thank you,

Hans