On Fri, 28 May 2004, Wez Furlong wrote:
> wez Fri May 28 09:25:51 2004 EDT
>
> Modified files:
> /php-src/ext/standard proc_open.c
> Log:
> Hopefully resolve proc_open build issues.
If proc_open.c is compiled by default (it currently is), you
are taking a huge risk here. To put it differently,
"Hopefully does not break the PHP 5 release (fingers crossed)".
#ifdef-based portability solutions are infinitely inferior to
autoconf-checks, because they only mature by breaking the
build for someone to initiate a feedback cycle. Doing this
for an initial, widely anticipated release of a product is
basically a guarantee for a lot of such feedback.
The current platform check for linux, sun, and irix will
catch a huge number of systems which either don't support pts
or have not them enabled. Are there any compelling reasons
why you would not want to do this properly?
I also just had a quick look at the code. It assumes that if
a C library contains code for grantpt etc, that the actual
system also has a working /dev/ptmx. This assumption is, of
course, completely unreliable. For example, the default
Linux 2.4 kernel setting is "pts disabled" -- although glibc
contains the support code you check for. Thus, the current
code will fail on a default Linux kernel.
With other words: The pts support of proc_open.c is anything
but mature and should not be enabled for the initial PHP 5
release.
- Sascha
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
