[PHP-DEV] Segfault with latest CVS
Hi, the following script makes this morning's CVS segfault: ?php require_once DB.php; ? DB.php is from the latest release of PEAR::DB. I can not provide a backtrace at the moment, but if you need one, just drop a mail. -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfault with latest CVS
On Tue Mar 11, 2003 at 10:5232PM +0100, Sebastian Bergmann wrote: Martin Jansen wrote: ?php require_once DB.php; ? Most likely this will be caused by 856 $this-$key = $arr[$key]; as variable member access causes a segfault in the compiler. Will this be fixed or has there been a decision to leave it segfaulting? -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for README.EXT_SKEL
Hi, on Debian Woody, one not only needs to change skeleton/create_stubs to use gawk instead of mawk, but it is also necessary to change ext_skel itself. With the attached patch this is noted in README.EXT_SKEL. -- - Martin Martin Jansen http://martinjansen.com/Index: README.EXT_SKEL === RCS file: /repository/php4/README.EXT_SKEL,v retrieving revision 1.9 diff -u -r1.9 README.EXT_SKEL --- README.EXT_SKEL 23 Oct 2002 21:31:12 - 1.9 +++ README.EXT_SKEL 6 Mar 2003 09:45:31 - @@ -17,7 +17,8 @@ [ Note that GNU awk is likely required for this script to work. Debian systems seem to default to using mawk, so you may need to change the -#! line in skeleton/create_stubs to use gawk explicitly. ] +#! line in skeleton/create_stubs and the cat $proto | awk line in +ext_skel to use gawk explicitly. ] If you don't need to test the existence of any external header files, libraries or functions in them, the module is already almost ready to be -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug 20147
Bug #20147 has been reported as a PEAR bug, but IMO this sounds more like a PHP problem. The user reports that he gets the error message /usr/src/ServerSoftware/PHP/php-4.3.0pre2/sapi/cli/php: relocation error: /usr/local/php/lib/php/extensions/no-debug-non-zts-20020429/xml.so: undefined symbol: XML_ParserCreate make[1]: *** [install-pear-installer] Error 127 make: *** [install-pear] Error 2 while the PEAR stuff is installed. Actually PEAR does not create anything like xml.so. Can anyone being more familiar with PHP's build stuff have a look at this? -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_AUTH_(USER|PW) not set
On Sat Oct 19, 2002 at 11:0608AM -0700, Rasmus Lerdorf wrote: You probably have an external auth module operating on the same request. I don't think so. Could you perhaps be a bit more verbose what you mean with external auth module? -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_AUTH_(USER|PW) not set
Sigh, I'm stupid: It was a dumb problem on my side. Sorry for any inconvenience. On Sun Oct 20, 2002 at 08:3156AM -0700, Rasmus Lerdorf wrote: As in any Apache mod_auth module. On Sun, 20 Oct 2002, Martin Jansen wrote: On Sat Oct 19, 2002 at 11:0608AM -0700, Rasmus Lerdorf wrote: You probably have an external auth module operating on the same request. I don't think so. Could you perhaps be a bit more verbose what you mean with external auth module? -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP_AUTH_(USER|PW) not set
The following script fails with the todays snapshot and with PHP
4.3.0-pre1:
?php
if (!isset($PHP_AUTH_USER)) {
header(WWW-Authenticate: Basic realm=\Foobar\);
header(HTTP/1.0 401 Unauthorized);
echo Access denied.;
exit;
} else {
echo Hello;
}
?
I looks like $PHP_AUTH_(USER|PW) are not set
properly. Register_globals is set to on, but the same problem also
occurs when setting it to off and using $_SERVER['PHP_AUTH_USER']
then. (Apache 1.3.26, Linux)
Any clues?
--
- Martin Martin Jansen
http://martinjansen.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [4.3.0-pre1] output handler 'ob_gzhandler' cannot be used twice
On Mon Oct 14, 2002 at 02:4353AM +0200, Jan Schneider wrote: Zitat von Yasuo Ohgaki [EMAIL PROTECTED]: Martin Jansen wrote: With PHP 4.3.0-pre1 I get the following error message in Chora: Warning: (null)() [ref.outcontrol]: output handler 'ob_gzhandler' cannot be used twice in Unknown on line 0 Script should be modified... What version has been used here? The start of output compression has already been moved to one single file unless we have overseen one file. The version of Chora was 2.0-cvs, but I don't remember when it has been installed; so it might be actually a bit outdated. -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [4.3.0-pre1] Weird encoding issue
Yet another issue with 4.3.0-pre1 and Chora: The screenshot that is available at http://www.martinjansen.com/stuff/chora-4.3.0-pre1.png shows that something (probably some character encoding stuff) is pretty much broken in pre1. Currently I don't have the time to track this down more detailed, but if you need more information, just ask. -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sapi/fhttpd + other sapi/cgi related things..
On Sat Oct 12, 2002 at 09:3104AM +0300, Jani Taskinen wrote: First of all, status of fhttpd...last version of it was released in 17-May-99..also last real updates to this code seem to have happened in PHP3. Can we get rid of this (most likely not even working) piece of code? +1. According to fhttpd.org the last version has been released on 17th May 99, which implies that development has been suspended forevermore. Uhu, there isn't even a bug type category for it on bugs.php.net ;-). -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [4.3.0-pre1] output handler 'ob_gzhandler' cannot be used twice
With PHP 4.3.0-pre1 I get the following error message in Chora: Warning: (null)() [ref.outcontrol]: output handler 'ob_gzhandler' cannot be used twice in Unknown on line 0 Did you change the behaviour of ob_gzhandler, which makes this warning legal, or is it a bug? -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Segfault in implode()
FYI: Yesterdays snapshot segfaults with the following line of code: ?php $foo = implode(, array()); ? -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PEAR and 4.3 release
On Tue Oct 01, 2002 at 06:3320PM +0200, Lukas Smith wrote: Mainly there are still too many questions marks regarding stuff like: - How are packages maintained (especially when the leading developer is gone ... PEAR DB currently seems to be an example of this with bugs hanging in the air and nobody feeling responsible) I guess sending patches to pear-dev should be the best way. - How are packages proposed and when are they accepted http://pear.php.net/manual/en/developers.contributing.howto.php - And when they are accepted how makes sure that the person gets the necessary access The PEAR administrators take care of the PEAR website accounts and the PHP Group does the same for CVS accounts. - A Guide to lessen the endless naming debates. http://pear.php.net/manual/ - Should packages be pearified before getting into pear cvs or is afterwards ok? Is there even a general rule? http://pear.php.net/manual/en/developers.contributing.php. - Where is a tutorial explaing all of the answers to above questions? Most of the stuff is explained in the PEAR developers guide: http://pear.php.net/manual/en/guide-developers.php The results of this would need to put into action. Therefore I think that PEAR will not be ready until the end of december. I think PEAR is pretty fare and it is absolutely read for a first appearance on the official stage. -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PEAR-DEV] Re: [PHP-DEV] PEAR and 4.3 release
On Tue Oct 01, 2002 at 07:0226PM +0200, Martin Jansen wrote: I think PEAR is pretty fare and it is absolutely read for a first appearance on the official stage. Doh, ignore this. Better: I think PEAR is absolutely ready for a first appearance on the official stage. -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PEAR-DEV] Re: [PHP-DEV] PEAR and 4.3 release
On Tue Oct 01, 2002 at 09:2106PM +0200, Edin Kadribasic wrote: make install part of php install needs to be fixed in the PEAR part. This currently does not work, at least for me on Linux. We are working on this. -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Latest cvs: error in mbstring
On Don Sep 26, 2002 at 09:3505 +0200, Martin Jansen wrote: The following error occurs when building latest CVS: ext/mbstring/mbstring.lo: In function `zif_mb_convert_case': /home/martin/cvs/php/php4/ext/mbstring/mbstring.c:2499: undefined reference to `php_unicode_convert_case' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Ok, this problem was fairly easy to solve as I in fact forgot to run ./buildconf. But now the next one occurs: make fails with: l_functions_cli.lo -lmysqlclient -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -ldl -o sapi/cli/php /usr/bin/ld: cannot find -lz collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 What's wrong there? The system is Debian Woody, Kernel 2.4.18 and I'm using Debian's precompiled MySQL 3.23.52. -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Latest cvs: error in mbstring
The following error occurs when building latest CVS: ext/mbstring/mbstring.lo: In function `zif_mb_convert_case': /home/martin/cvs/php/php4/ext/mbstring/mbstring.c:2499: undefined reference to `php_unicode_convert_case' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] xslt_process segfaults with illegal parameters
As the subject already mentions, xslt_process() segfaults when passing an illegal second or third parameter to it. Example: ?php $var = 'lala'; $xh = xslt_create(); $result = xslt_process($xh, $var, 'sample.xsl'); // segfault ? Instead of segfaulting, PHP should raise a warning/error in order to tell the user what went wrong, no? -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Segfault in 4.2.3RC2
Obviously PHP 4.2.3RC2 segfaults when using wordwrap() with the following configure options: './configure' \ '--with-config-file-path=/etc' \ '--with-exec-dir=/var/www/php-bin' \ '--enable-safe-mode' \ '--enable-calendar' \ '--with-mysql=/usr/local/mysql/current' \ '--with-pgsql=/usr/local/pgsql/current' \ '--with-mm' \ '--with-zlib' \ '--with-bz2' \ '--enable-memory-limit' \ '--disable-debug' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-trans-sid' \ '--with-regex=system' \ '--enable-track-vars' \ '--with-recode' \ '--enable-xslt' \ '--with-xslt-sablot=/usr' \ '--with-expat-dir=/usr' (I know that the configure options aren't that nice possibly, but they should give you the clue how the system is set up.) The script to reproduce the segfault can be found at http://www.martinjansen.com/php/segfault-4.2.3RC2.txt. If you need more information (backtrace etc.), just ask. -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfault in 4.2.3RC2
On Mit Sep 04, 2002 at 09:3724 +0200, [EMAIL PROTECTED] wrote: On Wed, 4 Sep 2002, Martin Jansen wrote: The script to reproduce the segfault can be found at http://www.martinjansen.com/php/segfault-4.2.3RC2.txt. If you need more information (backtrace etc.), just ask. That link gives a four oh four to me... Sorry - please try again. -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfault in 4.2.3RC2
On Wed Sep 04, 2002 at 09:3027PM +0200, Martin Jansen wrote: Obviously PHP 4.2.3RC2 segfaults when using wordwrap() with the following configure options: If it helps you, attached you'll find the backtrace of the crash. -- - Martin Martin Jansen http://martinjansen.com/ #0 0x402c1af6 in chunk_alloc () from /lib/libc.so.6 #1 0x402c1814 in malloc () from /lib/libc.so.6 #2 0x80d45ec in _emalloc (size=43) at zend_alloc.c:165 #3 0x80e54ef in zend_hash_add_or_update (ht=0x8142ee8, arKey=0x818bd24 wrapped, nKeyLength=8, pData=0xbfffe354, nDataSize=4, pDest=0xbfffe368, flag=1) at zend_hash.c:260 #4 0x80f42ed in zend_fetch_var_address (opline=0x818a8c8, Ts=0xbfffe38c, type=1) at ./zend_execute.c:575 #5 0x80f6072 in execute (op_array=0x8186584) at ./zend_execute.c:1239 #6 0x80e22fe in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:812 #7 0x8063166 in php_execute_script (primary_file=0xb790) at main.c:1383 #8 0x8060d53 in main (argc=3, argv=0xb80c) at cgi_main.c:778 #9 0x4026cbaf in __libc_start_main () from /lib/libc.so.6 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] MFH -R php4/pear/* files
On Thu Aug 29, 2002 at 08:1348PM +0200, Christian Stocker wrote: as i understand the core pear developer, it's only the pear-installer which should be merged into 4.2.3, not all the other packages (they can stay, where they are now). So only pear/PEAR/ has to be merged (IIRC) The original plan was to only bundle the PEAR installer and all packages, which are required to make it work, with PHP 4.3.0. All other components should stay outside and must be installed via this installer. Actually everyone must be aware that this will cause a bazillion of bug reports stating that people can't find DB.php or something else which has been bundled with PHP forever. To avoid this we might decide if the most popular PEAR packages (DB) will still be bundled. Anyways, the release cycle for 4.3.0 has already gone pretty far, so I think that this decision is over to the release masters (Zeev, Derick?) and Stig. -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] MFH -R php4/pear/* files
On Thu Aug 29, 2002 at 10:4027PM +0200, [EMAIL PROTECTED] wrote: On Thu, 29 Aug 2002, Martin Jansen wrote: Anyways, the release cycle for 4.3.0 has already gone pretty far, so I think that this decision is over to the release masters (Zeev, Derick?) and Stig. The release cycle for 4.3.0 is totally nowhere yet :) Doh, that's because of the incredible heat in Germany ;-). But if you mean 4.2.3 then I won't be very happy with putting new PEAR stuff in there now this late in the process (one week before release). +1. Let's continue the discussion when PHP 4.3.0 will be *really* released. -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Errors while building latest snapshot
While building the latest snapshot, I get the following error during make: ext/standard/info.lo: In function `php_print_info': /home/martin/source/php4-200208140300/ext/standard/info.c:233: undefined reference to `iconv_globals' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 My configure options are: './configure' \ '--with-apxs=/usr/local/apache/current/bin/apxs' \ '--with-mysql=/usr/local/mysql/current/' \ '--with-pgsql=/usr/local/pgsql/current/' \ '--with-interbase=/opt/interbase/' \ '--with-zlib' \ '--enable-ftp' \ '--with-mcal=/usr/include/mcal/' \ '--with-gettext=/usr/local/' \ '--enable-track-vars' \ '--enable-url-includes' \ '--enable-trans-sid' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-sockets' \ '--enable-bcmath' \ '--with-config-file-path=/etc' \ '--with-sablot=/usr' \ '--with-xmlrpc' \ '--enable-tokenizer' \ $ Any clues? -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Errors while building latest snapshot
On Thu Aug 15, 2002 at 01:5043AM +0200, Marcus Börger wrote: Could you try cvs version again? Build fine now. Thanks for your help. -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] MySQL - LOAD DATA LOCAL INFILE
On Fri Aug 09, 2002 at 02:1206AM +0200, Georg Richter wrote: With an external libmysql (and also with the integrated libmysql, which doesn't support disable load data), we have a little security hole, because in safe_mode it is possible to load (and view) all the data, which is under access of the webserver). It should be obvious for everyone that PHP can't protect all external libraries in safe mode. I would like to disable LOAD DATA LOCAL INFILE in safe mode. However this will generate a lot of trouble, since users without shell access aren't able to import data in their mysql-db. -10^6 on this idea. People need to have the chance to import stuff into their databases. -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PEAR-DEV] Binary extensions via PECL
On Fri Jul 26, 2002 at 06:2117PM +0300, Marko Karppinen wrote: 1. Someone from the PHP Group will be designated the PHP Certificate Authority. This person will, on a mostly non-connected system, grant certificates for all PEAR/PECL package maintainers. He will also maintain a Certificate Revocation List on www.php.net. The PHP CA public key will be distributed with all copies of PHP. 2. Package maintainers will prepare their packages like before. In addition to the package, they will prepare an S/MIME message that contains the SHA1 (RFC3174) hash of the package in question. The maintainers will cryptographically sign this message and send it to the repository along with the package. 3. The PEAR/PECL installer will fetch both the package and the accompanying S/MIME message, verifying that the signatory has been certified by the PHP CA. The installer will also check that the signatory has not been placed on the php.net CRL. Finally, the installer will determine whether the SHA1 hash in the message matches with the hash of the downloaded package. If not, the installation is aborted. Will this process only apply for PECL extensions (as your subejct implies) or will it apply for PEAR packages also? Generally, your proposal sounds fine for me. - We need a volunteer for the PHP CA. Stig sounds like the man for this. - After this change the OpenSSL extension will be a significant enabler of the PEAR/PECL infrastructure. It should be on by default (if the host has OpenSSL installed). What's with Windows? Does it support OpenSSL by default? -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1
On Mon Jul 22, 2002 at 06:0054PM +0200, Melvyn Sopacua wrote: I'm not sure I can upgrade all my installations, in due time, because of backwards compatibility issues in some extensions. Only PHP 4.2.* is affected by the vulnerability. PHP 4.2.2 is similar to PHP 4.2.1 but contains just the patch to fix the bug. So if you are running PHP 4.2.* you should be able to update without breaking anything. If you are running PHP 4.2.0 you don't need to worry about the vulnerability. - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How can I search in the dev list?
On Thu Jul 18, 2002 at 11:1525AM -0600, Braulio José Solano Rojas wrote: Is there an interface to search through the dev list? http://marc.theaimsgroup.com/?l=php-dev - Martin -- Martin Jansen - [EMAIL PROTECTED] http://martinjansen.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL
On Thu, 23 May 2002 20:08:48 +0200, Lukas Smith wrote: It sounds to me like something like webservices.php.net would be in order. I don't think that having yet another subdomain does make much sense. Actually I prefer to have documentation for whatever comes out of this discussion in the PHP or in the PEAR manual. - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL
On Thu, 23 May 2002 15:27:00 -0700, Shane Caraveo wrote: Markus Wolff wrote: The best thinkable solutions would be: a) Bundle a library like PEAR::SOAP with PHP that is modified in a way that it automatically detects if the xmlrpc-epi extension is installed. If so, PEAR::SOAP only acts as a wrapper class around the calls to the extension. Else, it uses its own, slower PHP routines. This is exactly what I've wanted to do. Just for the records: I like this plan and I think that we should try to push this forward. Brad: Without knowing very much about your SOAP project: Do you think that it is possible to merge your code with the xmlrpc-epi extension? - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Errors when building HEAD
On Thu, 23 May 2002 12:33:12 -0400, Jon Parise wrote: On Wed, May 22, 2002 at 09:44:35AM +0200, Martin Jansen wrote: On Wed, 22 May 2002 09:21:47 +0200, Markus Fischer wrote: autoconf 2.53 isn't supposed to work. Try with 2.13 After downgrading to 2.13, I now get the error messages on can find in the attached buildconf_errors.txt. After running ./configure then results in: checking whether to include debugging 2.13... ./configure: line 11416: syntax error near unexpected token `else' ./configure: line 11416: `else' Any clues? Try running ./cvsclean and then ./buildconf. The problem persists. Actually I think that there is something fu**ed up pretty much on the system, since it works for me on another Linux box. - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Errors when building HEAD
On Wed, 22 May 2002 09:21:47 +0200, Markus Fischer wrote:
autoconf 2.53 isn't supposed to work. Try with 2.13
After downgrading to 2.13, I now get the error messages on
can find in the attached buildconf_errors.txt. After running
./configure then results in:
checking whether to include debugging 2.13... ./configure: line 11416:
syntax error near unexpected token `else'
./configure: line 11416: `else'
Any clues?
- Martin
--
Martin Jansen, [EMAIL PROTECTED]
http://www.martin-jansen.de/
martin@urmel:~/cvs/php/php4 ./cvsclean
martin@urmel:~/cvs/php/php4 ./buildconf
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: automake version 1.4 (ok)
buildconf: libtool version 1.4.2 (ok)
rebuilding configure
autoconf: Undefined macros:
***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
configure.in:132:dnl AC_AIX needs to be before any macros that run the C compiler.
configure.in:133:AC_AIX
configure.in:167:AC_MSG_RESULT([$php_cv_cc_dashr])
configure.in:178: AC_MSG_RESULT([$php_cv_cc_rpath])
configure.in:198:AC_MSG_RESULT(${1}.${2} (ok))
configure.in:261:AC_MSG_RESULT([$PHP_SAPI])
configure.in:302: AC_DEFINE(HAVE_LIBSOCKET,1,[ ]) ], [
configure.in:328: AC_DEFINE(HAVE_LIBNSL,1,[ ]) ],[
configure.in:331: AC_DEFINE(HAVE_LIBNSL,1,[ ]) ], [])
configure.in:357: AC_DEFINE(HAVE_LIBSOCKET,1,[ ]) ], [
configure.in:360: AC_DEFINE(HAVE_LIBRESOLV,1,[ ])
configure.in:464: AC_DEFINE(HAVE_SOCKADDR_STORAGE,1,[Whether you have struct
sockaddr_storage])
configure.in:474: AC_DEFINE(HAVE_IPV6,1,[Whether you have IPv6 support])
configure.in:553: AC_DEFINE(HAVE_GETADDRINFO,1,[Define if you have the getaddrinfo
function])
configure.in:559:PHP_AC_BROKEN_SPRINTF
configure.in:579:dnl AC_MSG_RESULT([$ac_cv_type_in_addr_t])
configure.in:581: AC_DEFINE(in_addr_t, u_int, [ ])
configure.in:663: AC_DEFINE(PHP_SAFE_MODE,1,[ ])
configure.in:665: AC_DEFINE(PHP_SAFE_MODE,0,[ ])
configure.in:675: AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,/usr/local/php/bin, [ ])
configure.in:676: AC_MSG_RESULT([/usr/local/php/bin])
configure.in:678: AC_DEFINE_UNQUOTED(PHP_SAFE_MODE_EXEC_DIR,$withval, [ ])
configure.in:679: AC_MSG_RESULT([$withval])
configure.in:682:AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,/usr/local/php/bin, [ ])
configure.in:683:AC_MSG_RESULT([/usr/local/php/bin])
configure.in:686: AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,/usr/local/php/bin, [ ])
configure.in:687: AC_MSG_RESULT([/usr/local/php/bin])
configure.in:702: AC_DEFINE(PHP_SIGCHILD, 1, [ ])
configure.in:704: AC_DEFINE(PHP_SIGCHILD, 0, [ ])
configure.in:711: AC_DEFINE(MAGIC_QUOTES, 1, [ ])
configure.in:713: AC_DEFINE(MAGIC_QUOTES, 0, [ ])
configure.in:736: AC_DEFINE(DEFAULT_SHORT_OPEN_TAG,1,[ ])
configure.in:738: AC_DEFINE(DEFAULT_SHORT_OPEN_TAG,0,[ ])
configure.in:749:AC_DEFINE(HAVE_DMALLOC,1,[Whether you have dmalloc])
configure.in:759: AC_DEFINE(HAVE_CRYPT,1,[ ])
configure.in:805:AC_MSG_RESULT([$PHP_VERSIONING])
configure.in:849: AC_DEFINE(ZTS,1,[ ])
configure.in:962:AC_DEFINE_UNQUOTED(PHP_BUILD_DATE,$PHP_BUILD_DATE,[PHP build date])
configure.in:964:AC_DEFINE_UNQUOTED(PHP_UNAME,$PHP_UNAME,[uname -a output])
configure.in:966:AC_DEFINE_UNQUOTED(PHP_OS,$PHP_OS,[uname output])
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Enabling ext/zlib by default
On Tue, 21 May 2002 08:13:31 +0200, Sebastian Bergmann wrote: I think we should make '--with-zlib' the default, and add '--disable-zlib', for the PHP 4.3.0 release, since the PEAR Installer relies on it. +1. If we don't do that, the install will not work on a lot of out of the box setups. - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Enabling ext/zlib by default
On 21 May 2002 08:46:54 +0200, Stig S. Bakken wrote: On Tue, 2002-05-21 at 08:13, Sebastian Bergmann wrote: I think we should make '--with-zlib' the default, and add '--disable-zlib', for the PHP 4.3.0 release, since the PEAR Installer relies on it. It's not supposed to, I've added nocompress options everywhere needed, so it should work just fine without zlib: I could have sworn that I got an error message some days ago when using PEAR on a pretty recent PHP version without zlib, but I may be wrong.. Even if you enable zlib by default, PHP does not bundle zlib, it would not be available on every system, and the installer would have to support uncompressed packages anyway. But it does not do any harm if we enable it by default, no? Additionally we would also save some bandwidth then. (Yes, I know that most PEAR packages are 20 KB :-). - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Enabling ext/zlib by default
On 21 May 2002 09:29:05 +0200, Stig S. Bakken wrote: Does the bzip2 extension work in Windows? Yup, it seems so. - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Errors when building HEAD
When running ./buildconf in latest CVS, I get the following errors: buildconf: checking installation... buildconf: autoconf version 2.53 (ok) buildconf: automake version 1.4 (ok) buildconf: libtool version 1.4.2 (ok) rebuilding configure configure.in:167: error: possibly undefined macro: AC_MSG_RESULT configure.in:302: error: possibly undefined macro: AC_DEFINE configure:88811: error: possibly undefined macro: _LT_AC_TRY_DLOPEN_SELF When running ./configure with some options then, I get Configuring Zend [...] checking for BSD-compatible nm... /usr/bin/nm -B ./ltconfig: ./ltconfig: No such file or directory configure: error: libtool configure failed . Is my system mis-configured or is there actually a problem in HEAD? - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Strange behaviour in arrays
Taking the following script: ?php $array = array(foo = true, bar = false ); print_r($array); ? The result of print_r is: Array ( [foo] = 1 [bar] = ) Shouldn't false in the array definition result to 0 instead of nothing? - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] highlight_string()
On Fri, 25 Jan 2002 11:57:27 +0100, Sebastian Bergmann wrote: Could highlight_string() be changed to (optionally) return the highlighted string? The following works, but is IMHO overhead ob_start(); highlight_string($string); $string = ob_get_contents(); ob_end_clean(); +1 - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Overloading Tags with PHP functions
On Tue, 15 Jan 2002 18:34:24 +0100, Kristian Köhntopp wrote: The following code is slow and very ad-hoc. Still, I'd like you to have a look at it and think about it - I'll gather reviews and opinions and probably turn it into C at some later time. For the ones which are unable to understand the german comment at line 45: This is the translation: # Recursion: # Apply xml_transformation on the result again in order # to also replace generated special tags. - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 5
On Wed, 2 Jan 2002 14:43:39 +0100, Edin Kadribasic wrote: The build process should be altered so that the standalone interpreter (cgi sapi) is always built so the traditional make make install installs /usr/bin/php no matter what sapi module was chosen. I'm +1 on this, even though I think that PHP isn't very well suited for shell jobs in comparison to Bash or Perl. Always building the CGI version would also help the PEAR command line installer a lot since it currently needs a PHP binary to be executed. - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-DEV] PECL (was PHP 5)
On Wed, 02 Jan 2002 20:39:44 +0200, Andi Gutmans wrote: However, if PECL doesn't become everything we hoped for within the next few months (possible) I don't think it should stop PHP 5. We could always have 5.1. At least we could have PHP 6 right after 5 :-). Anyway, that's not too important right now. We still haven't heard from anyone what work has been done on PECL. Currently there has not been much work on the PECL installer. Our current aim is to provide a solid installation procedure for PEAR components. Installing PECL extensions is a bit trickier IMO: You have to consider ./configure files, build processes, plugging configuration directives in php.ini etc. I think without a lot of work done by many of us here on php-dev it'll probably not gain enough momentum. +1. I suggest we move PECL either to its own mailing list or to php-dev. +1 for it's own mailing list. Additionally we could perhaps set up an own CVS module for PECL. (Currently it resides in /pear/PECL.) Guys? - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Moving extensions to PECL
On 31 Dec 2001 19:18:59 -, Jim Winstead wrote: Jon Parise [EMAIL PROTECTED] wrote: Are there any well-founded objections to this (either in practice or principle)? no objections, but one thing that should be considered is what happens to the documentation for these extensions The documentation of the extensions can be easily merged in the peardoc repository. Right now there is no automated build for the manual, but you promised to help us with that in 2002, no? :-) - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Moving extensions to PECL
On Tue, 1 Jan 2002 18:36:57 +0100, Egon Schmid wrote: Well, I know librians will love the YAZ extension. I suggest to move the documentation in a new part in the PHP Manual. I think of a split of the original Function Reference in something like Basic Function Reference and Extended Function Reference. If yaz is going to become part of PECL (= part of PEAR), documentation should be placed in the PEAR manual. Everything else is less intuitive and will irritate people IMO. - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Moving extensions to PECL
On Tue, 1 Jan 2002 19:55:33 +0100, Egon Schmid wrote: Are you sure that librians find the PEAR documentation? When they find the PHP documentation, they can also find the PEAR documentation, no? :-) As I can see PEAR and PHP documentation differs in many things. What kind of differences are you talking about? - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Moving extensions to PECL
On Tue, 1 Jan 2002 10:09:51 -0800, Jim Winstead wrote: i was thinking more along the lines of something that allowed the documentation for an extension to be managed on its own, Documentation somewhere is better than documentation nowhere ;-). Anyways, I don't have a really strong opinion when it comes to documentation for extensions that are moved over to PECL. If people want to leave it in phpdoc that's ok for me. - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-DEV] PECL module
On Tue, 25 Dec 2001 13:31:40 +0900, Yasuo Ohgaki wrote: I hope there is more explanation about PECL in PHP source. How about to have README.PECL to let develpers/users know status of PECL, what it is, what kind of module goes to PECL, etc. I've written some documentation about PECL, that I will commit to the PEAR manual shortly. Back to the cookies now :-), - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-DEV] [FRC]Session module related issues
On Thu, 20 Dec 2001 14:41:43 +0900, Yasuo Ohgaki wrote: 4) Where document should be? If your session handler will be part of PECL, it should be documented in the upcoming PEAR manual. Have a look at the CVS module peardoc to get a feeling for it. Basically I think it would be nice to have this in PECL, since it is no real 'core' part of PHP and so it does not really fit in php4/ext, eventhough it requires the session extension to be enabled. - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-DEV] Re: [FRC]Session module related issues
On Thu, 20 Dec 2001 22:38:03 +0900, Yasuo Ohgaki wrote: Then msession may have the same problem that I mentioned. Since session module can be disabled, if users load extension depands on session module, it will end up with undefined symbol error. This is not nice... But that's actually the problem of the developer: If he want's to use your module, he simply has to ensure that the session module is compiled in his PHP version. Basically, this is the same with PEAR DB e.g.: If I want to use it's abstraction layer for Oracle, I have to make sure that Oracle is available within PHP. - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-DEV] Re: [FRC]Session module related issues
On Thu, 20 Dec 2001 19:58:10 +0900, Yasuo Ohgaki wrote: You missed issues here 1) It highly depends on Session module. I don't see a problem here. The developer has to take care that session is available when he wants to use your module. That's what dependencies are for :-). 2) It does not work as standalone module at all. Note this down in the documentation and you are done. 3) It will fail to load with undefined symbol when PHP is compiled with --disable-session. See my answer for 2) 3) It does not provide any function to users. I can't see a reason here that is speaking against integrating your module in PECL. 4) Where document should be? See my reply to your first mail. 5) How to handle include files required for session save handler module? I can't really answer that question since I'm not familiar enough with PHP's internals. - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: Re[2]: [PHP-DEV] [NEW EXTENSTION]: templates
On Wed, 5 Dec 2001 15:15:29 +0100, Daniel Lorch wrote: it's nice to see that everyone wants to develop extensions for PHP, but why do these extension go all into the main CVS tree? why not keep PHP more modular? New extension (ike the one, we are talking about) will go to PEAR and will not be included in the main source tree (unless they are extremely important). Or did I miss something? - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: Re[2]: [PHP-DEV] [NEW EXTENSTION]: templates
On Wed, 5 Dec 2001 16:17:29 +0100 (CET), [EMAIL PROTECTED] wrote: On Wed, 5 Dec 2001, Andrei Zmievski wrote: On Wed, 05 Dec 2001, Björn Schotte wrote: I suggest ext/template being extemely important. Sorry, but I am completely against it. I agree with Andrei here. If an templating extension is bundled with PHP, it becomes the 'defacto supported' template engine. In other words, we will say that this is the best template engine, because it is bundled with PHP. I'm also not sure, if the template extension is important enought to be bundled with PHP and I think, that it might fit better in PEAR, but: What is with PEAR DB? Is it also the defacto standard, because it is bundled with PHP? - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP Module for reading/writing Palmtop .PDB files..
On 03 Dec 2001 09:56:24 +0100, Mathieu Kooiman wrote: I'm almost done writing a PHP module for my library, pdb-lib, which enables you to read and write .PDB files on the PC. This library is not YET available. I have some question pending somewhere and after that I'll release it (GPL). Is there any interest in adding this to the PHP dist ? I would add it to PEAR instead of the PHP source tree. - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Patch: Nested comments
On Tue, 27 Nov 2001 12:15:39 +0100, Markus Fischer wrote: Although my vote doesn't count much here :-) I'm for it... ... but it would be a problem for 4.x I guess because this horribly breaks BC when/if there's a new 4.x release and people start using it. But it would be nice to have it in ZE2. +1 - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Out of date modules etc
On Fri, 23 Nov 2001 14:32:49 -, James Moore wrote: CCVS has now been dropped by redhat (it will be replaced by MCVE), the module doesnt really seem to be supported either. With sablotron going the same way (for different reasons though) perhaps we should create a unsupported or and old directory in the pear c extension repository for these modules to reside and move them out of php4/ext. I don't think we should pollute PEAR with such old crap. Why not remove them completely? - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-DEV] PHPDoc Development Status
On Thu, 22 Nov 2001 16:06:35 +0100, Andre Gildemeister wrote: - shouldn't PHPDoc become an official extension either? (ext/phpdoc) I don't see a good reason for that. - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Removing ext/sablot from 4.1?
On Sat, 17 Nov 2001 16:03:32 +0100, Thies C. Arntzen wrote: i think we should remove it (also from CVS) as it is non maintained and superceeded by a newer, better thingie. Yeah, nuke it. +1 - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] getenv HTTP_POST_VARS
On Sat, 17 Nov 2001 16:34:45 +0100, Pierre-Alain Joye wrote: Un post directement sur une page phpinfo : Please speak english on this list ;-). - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] md5sum() patch
On Thu, 15 Nov 2001 17:25:24 +0100 (CET), [EMAIL PROTECTED] wrote: On Thu, 15 Nov 2001, Alessandro Astarita wrote: In this way you load in memory all the file contents and then you hash it. It's not the same. My function is the php version of the md5sum utility that you can find at example in Linux (textutils package). Then this will do the same: $sum = `md5sum filename`; I think it would be much nicer to have such a function in the PHP core, than always executing an external program. - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug in PHP 4.2.0-dev
The following script produces a pretty weird output:
?php
class Net_Portscan
{
function checkPort($host, $port)
{
$socket = @fsockopen($host,
$port,
$errorNumber,
$errorString,
30);
if (!$socket) {
return 0;
}
return 1;
}
}
echo Net_Portscan::checkPort(127.0.0.1, 80);
?
The result of the checkPort() call should be either 0 or 1, right?
When executing this script on PHP 4.2.0-dev (latest snapshot),
Apache 1.3.22 and Linux 2.4.0, the output is a number with 9
digits (e.g. 135197452), that randomly changes with each request.
With PHP 4.0.6, Apache 1.3.20 and Debian 2.2r3 it works without
a problem.
Any hints?
- Martin
--
Martin Jansen, [EMAIL PROTECTED]
http://www.martin-jansen.de/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Fix for bug #11563
On Mon, 05 Nov 2001 15:42:57 +0100, Martin Jansen wrote: On Sun, 04 Nov 2001 20:10:51 +0200, Andi Gutmans wrote: The patch looks OK if open_basedir is really supposed to stop people from stat()'ing files which aren't underneath the open_basedir path. I think this behaviour is ok, isn't it? Has anybody been looking at this so far? - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] class xxx extends a_class_from_the_include_path - problem
On Sat, 10 Nov 2001 19:24:36 +0100, Wolfram Kriesing wrote:
it prints
i am super2
i am super1
i am super1
i am super1
i am super1
i am super1
and so on
if class super _doesnt_ extend PEAR the expected output is printed
i am super2
i am super1
i am super
Your testscript generates the following output with 4.2.0-dev, no matter
if super extends from PEAR or not:
i am super2
i am super1
i am super
- Martin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Fix for bug #11563
In http://bugs.php.net/bug.php?id=11563 there is a patch for the reported bug. Is there anything speaking against applying this patch? - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #13846 Updated: Patch: Use [ ] as shortcut forarray()
On Sun, 28 Oct 2001 17:40:40 +0200 (EET), Jani Taskinen wrote:
On Sun, 28 Oct 2001, Zakaria wrote:
For example:
Perl: $list = (1, 2 ,3, 'four', 'five', (6.1, 6.2, 6.3));
Python: list = [1, 2, 3, 'four', 'five', [6.1, 6.2, 6.3]]
Ruby: list = [1, 2, 3, 'four', 'five', [6.1, 6.2, 6.3]]
Tcl: set list {1 2 3 four five {6.1 6.2 6.3}}
PHP: $list = array(1, 2, 3, 'four', 'five', array(6.1, 6.2, 6.3));
Which clearly shows that PHP is readable and all the other languages are
not. -10 from me to this feature.
I could have never explained that better. Please _don't_ introduce such
a syntax in PHP.
- Martin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.1.0RC1 ?
On Sun, 21 Oct 2001 11:55:12 +0200, Jean-Claude Schopfer wrote: Where is PHP 4.1.0RC1 ? http://www.php.net/~ssb/php-4.1.0RC1.tar.gz - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity
On Mon, 1 Oct 2001 09:57:12 -0400, Jon Parise wrote: On Mon, Oct 01, 2001 at 10:12:52AM +0200, Andi Gutmans wrote: I am OK with such an ambiguity error. What about the rest of the people? I think it will be okay. Anyone using (non-newbie) features like namespaces and ternary operations should understand the ramifications of stressing the syntax. That's not to say that PHP should become complicated, but if ternary operations are the only place this ambiguity shows its face, we can deal. People using namespaces and ternary operations aren't normally beginners or people who only want to create a guestbook for their website. So IMO the whole usage of the namespace concept is allowed to be a bit more complicated than 'usual' PHP. - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity
On Mon, 1 Oct 2001 10:08:02 -0500, Andrei Zmievski wrote: For the record, I'd vote for either unifying classes and namespaces (I like that approach), or failing that, using :::. +1 - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] class destructors?
On Mon, 24 Sep 2001 14:49:53 -0400 (EDT), [EMAIL PROTECTED] wrote: Just a thought. I have been using PHP for a while now, and have wondered why it does not support class destructors? It would be a very useful thing. Have a look at PEAR: We are using register_shutdown_function() to emulate destructors. If you have more questions concerning this topic, you should ask them on [EMAIL PROTECTED] - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] API Thoughts?
On Mon, 27 Aug 2001 00:29:26 -0400 (EDT), Sterling Hughes wrote: The current way I have it organized is as follows: php4/pear/ADT.php php4/pear/ADT/LList.php php4/pear/ADT/Stack.php php4/pear/ADT/Queue.php php4/pear/ADT/AVLtree.php php4/pear/ADT/BTree.php php4/pear/ADT/RBTree.php php4/pear/ADT/Heap.php php4/pear/ADT/Set.php Just a sidenote: All new contributions to PEAR have to be commited to /pear, not to /php4/pear (this directory is only there until the PEAR infrastructure is running). - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Chora installed
On Thu, 26 Jul 2001 09:02:10 -0700 (PDT), Rasmus Lerdorf wrote: Chuck installed his PHP-based cvs browsing app. It is available at http://chora.php.net. Go have a look. I think it looks really good and we should probably make it the default for http://cvs.php.net. +1 - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-PATCH] XMLRPC Pear Patch
On Sun, 22 Jul 2001 12:02:18 +1000, Matt Allen wrote: Attached is a small patch tp pear/XML/RPC.php. Thanks, I applied your patch. If you have more patches for PEAR classes, please send them to [EMAIL PROTECTED] instead of [EMAIL PROTECTED] - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] rtfm
On Sat, 07 Jul 2001 11:42:02 +0300, Andi Gutmans wrote: Didn't we decide on nuking ext/rtfm? Can I go ahead? Isn't this extension already removed? - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Sablotron leaks
On Sun, 24 Jun 2001 10:32:06 -0700 (PDT), Rasmus Lerdorf wrote: $xsl = join(, file(x.xsl)); Blah... I see this a lot. We should probably just relent and make a function that reads an entire file into a string. +1 - Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] [feature request] return name of current function
Hi
Is there anything that is speaking against a function
or a constant, that contains the name of the current
function?
This might be especially useful for situations like
?php
function print_error($name) {
echo "An error occured in ".$name;
}
function foo() {
if ($error)
print_error('foo');
}
?
where you pass the name of the function (in this
case the function, where the error occurs) to
another function. If there would be function or
a constant to return the current name, you could
simply type:
function foo() {
if ($error)
print_error(cur_function[()]);
}
So if you rename the function you do not need
to change the (perhaps multiple) call(s) for
print_error().
Martin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Fwd: Undelivered Mail Returned to Sender
Could please anyone from Pentap have a look at this? Sth. with their mail delivery seem to be wrong ... ==BEGIN FORWARDED MESSAGE== Date: Wed, 21 Feb 2001 22:24:46 +0100 (CET) From: [EMAIL PROTECTED] (Mail Delivery System) Subject: Undelivered Mail Returned to Sender To: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] This is the Postfix program at host bilbo.pentap.net. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please contact [EMAIL PROTECTED] If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program [EMAIL PROTECTED]: unknown user: "designmm" ===END FORWARDED MESSAGE=== [PHP-DEV] Bug in date()- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Problem with strings on Win32
On Tue, 20 Feb 2001 20:40:04 +0100, Sebastian Bergmann wrote: The following code ?php $string = "test"; print "*".$string."*br"; var_dump($string); ? outputs ** string(6) "" On my machine (Windows 2000 Professional German) everything works fine: | [d:\php\php4.0.4pl1]php | ?php | $string = "test"; | | print "*".$string."*br"; | var_dump($string); | ? | ^Z | X-Powered-By: PHP/4.0.4pl1 | Content-type: text/html | | *test*brstring(6) "test" | | [d:\php\php4.0.4pl1] Using PHP 4.0.4pl1. Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] wrong implementation of isset()?
The following was reported today in the german language newsgroup
news:de.comp.lang.php:
?php
$a = NULL;
if (isset($a)) { print "ok, du hast recht"; }
?
Shouldn't this script generate some output? IMO $a is set
and isset() should return true.
The manual says:
"isset -- Determine whether a variable is set"
So following the manual means that there _has_ to be
output because $a is set in fact.
Or am I wrong?
-Martin
--
Martin Jansen mailto:[EMAIL PROTECTED]
Monschau, Germany http://martin-jansen.de
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] wrong implementation of isset()?
On Tue, 6 Feb 2001 13:43:29 -0600, Andrei Zmievski wrote: On Tue, 06 Feb 2001, Bjoern Hoehrmann wrote: NULL == not set Great analysis. What about answering the question? Stanislav Malyshev said some months ago this is 'strange', see the discussion around bug 6076. Tell us at least, why this actually isn't strange. By default, any unset variable has value NULL - and isset(NULL) returns false to indicate that. Similarly, assigning NULL to a variable unsets it. But if I declare the variable in my script (and in the namespace), it's existing, no matter which value it has (String, Integer, NULL or whatever). As a result of that, isset() should return true. -Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] string replacement
On Mon, 22 Jan 2001 16:28:09 +0100 (CET), Derick Rethans wrote: On Mon, 22 Jan 2001, Andrei Zmievski wrote: I could modify str_replace() to have the same behavior with regard to arrays as preg_replace() - if people agree that it's a good idea.. I think it's a good idea, makes the language more consistent. +1 -Martin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
