Re: 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. On Tue, 6 May 2003, Hans Zaunere wrote: > > 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 > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > >