Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:1316
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Tue, 6 May 2003 16:18:15 +0100 (BST)
To: Hans Zaunere <hans@nyphp.org>
cc: internals@lists.php.net
In-Reply-To: <20030506150642.44449.qmail@web12805.mail.yahoo.com>
Message-ID: <Pine.LNX.4.53.0305061608300.17867@zaneeb.brainnet.i>
References: <20030506150642.44449.qmail@web12805.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] streams, stderr/out and zend_fprintf ?
From: wez@thebrainroom.com (Wez Furlong)

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
>
>
>