[PHP-DEV] Bug #10739 Updated: Zlib compile fails
ID: 10739 Updated by: sniper Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating system: PHP Version: 4.0.5 Assigned To: Comments: Forgot the url to that RC: http://www.php.net/~andi/php-4.0.6RC1.tar.gz Previous Comments: --- [2001-05-16 02:49:21] [EMAIL PROTECTED] And how does the PHP 4.0.6RC1 work for you? --Jani --- [2001-05-09 09:02:01] [EMAIL PROTECTED] I get the same thing, and the common link seems to be IMAP - somewhere between revision 1.27 and the current version of ext/imap/config.m4, the build was broken such that it doesn't add the right include paths - the zlib test compile fails because the mm_* callbacks that libc-client expects to find aren't defined in any of the included headers. I'll try and dig up a config.log message later if this doesn't ring a bell for someone. --- [2001-05-08 18:43:39] [EMAIL PROTECTED] There is more likely something else that fails. Check the config.log file for more info. --Jani --- [2001-05-08 18:36:05] [EMAIL PROTECTED] My compile options follow: ./configure --prefix=/usr/local/php --disable-debug --enable-shared --enable-inline-optimization --with-apxs=/usr/sbin/apxs --with-gd --with-jpeg-dir=/usr --with-png --with-zlib --with-db2 --with-db3 --with-gdbm --disable-debug --enable-sockets --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-yp --enable-ftp --enable-wddx --with-mysql --with-xml --disable-short-tags --enable-trans-sid --with-imap --with-mcrypt --with-mhash --enable-bcmath --with-ttf --with-t1lib --with-pgsql --with-ldap --- [2001-05-08 18:32:59] [EMAIL PROTECTED] Zlib fails to compile even though it is properly installed. configure: error: Zlib module requires zlib = 1.0.9. [root@websmith php-4.0.5]# rpm -qa | grep zlib zlib-1.1.3-22 zlib-devel-1.1.3-22 Bug 8575 says; [2001-04-10 09:45:37] [EMAIL PROTECTED] No feedback. If this happens with soon to be released PHP 4.0.5 too, reopen this bug report. --Jani --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10739edit=2 -- 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 #10615 Updated: JPEG size info not properly returned on unmodified JPEG images from digicam
ID: 10615 User Update by: [EMAIL PROTECTED] Status: Closed Bug Type: GetImageSize related Operating system: Linux 2.4.4 (Redhat 7.0) PHP Version: 4.0.5 Description: JPEG size info not properly returned on unmodified JPEG images from digicam All fixed. Both links now work properly again. Previous Comments: --- [2001-05-16 00:53:22] [EMAIL PROTECTED] Should be fixed in CVS now. --Jani --- [2001-05-03 12:46:30] [EMAIL PROTECTED] Try this instead (updated my original code to use ImageMagick instead - slower, but functional). I created a few files which may help. Script 1 calls an image that doesn't work properly. Script 2 calls an image from the same camera, however the image was rotated using a lossless method before it was uploaded. It was, however, modified none the less. Script 1: http://pictures.ourjohnsonfamily.com/2000/april%2002,%202000%20-% 20disneyland%20car%20ding/index2.php Script 1's source: http://pictures.ourjohnsonfamily.com/2000/april%2002,%202000%20-% 20disneyland%20car%20ding/index2.phps Script 2: http://pictures.ourjohnsonfamily.com/2000/april%2002,%202000%20-% 20disneyland%20car%20ding/index3.php Script 2's source: http://pictures.ourjohnsonfamily.com/2000/april%2002,%202000%20-% 20disneyland%20car%20ding/index3.phps Hope this helps, and sorry for changing out from under you. -Rick --- [2001-05-02 19:43:36] [EMAIL PROTECTED] That example script of your doesn't have any getimagesize() calls in it. So please add one example script into this bug report that doesn't work. --Jani --- [2001-05-02 12:58:54] [EMAIL PROTECTED] Issue noted in 4.0.5 and 4.0.6-dev. Currently running 4.0.6-dev Location where issue can be viewed. http://pictures.ourjohnsonfamily.com/2001/april%2014,%202001%20-%20easter%20eve%20and%20prego%20pics/ On demo page - thumbnails in left frame should display image dimensions. Since 4.0.5, image info is only obtainable if image file has been modified in any way. If images have been pulled straight from digicam, information cannot be displayed. Script source can be viewed here: http://www.htmlspinnr.org/photodisplay.phps Find function GetDimension, this is where GetImageSize is called. Function worked properly in 4.0.4pl1, so I'm not blaming code. configure string: ./configure '--prefix=/usr' '--with-mysql=/usr' '--with-apxs' '--sysconfdir=/etc' '--with-config-file-path=/etc' '--enable-inline-optimization' '--enable-ftp' '--enable-ssl' '--enable-imap' '--with-gd' '--with-gd-dir=/usr/lib' '--with-jpeg' '--with-png' '--with-jpeg-dir' '--with-png-dir' '--with-freetype-dir=/usr/local/lib' '--enable-gd-native-ttf' other runtime info (incl. compile string, etc.) http://www.ourjohnsonfamily.com/info.php ( a file containing ? PHP_INFO ?) --- Full Bug description available at: http://bugs.php.net/?id=10615 -- 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 #10754 Updated: parsing CDATA with special characters
ID: 10754 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: XML related Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: Could you please try with the latest release candidate: http://www.php.net/~andi/php-4.0.6RC1.tar.gz using it I can parse your example XML file just fine. --Jani Previous Comments: --- [2001-05-09 11:28:09] [EMAIL PROTECTED] Parsing a XMLdocument that contains CDATA parts produces errors. Also the parser should leave the CDATA it still tries to parse it. Here is my XMLdoc : ?xml version='1.0' encoding='UTF-8'? cresult content title ![CDATA[Münchenbbold/b ]] /title text ![CDATA[pparagraph bbold/b /p]]/text /content /cresult The parser complains about the letter 'ü' in the second line. When I change it to 'ä' the document is parsed nicely. Other combinitions like 'äü' are also parsed nicely. Must be a bug? My configure line: './configure' '--with-apache=/usr/local/src/apache_1.3.19' '--with-mysql=/usr/local/mysql' '--with-zlib-dir=/usr/local/lib' '--with-ftp' '--with-gd' '--with-jpeg-dir=/usr/local/lib' '--with-xml' '-with-dom=/usr/local/lib' '--enable-versioning' '--enable-track-vars=yes' '--enable-url-includes' '--enable-sysvshm=yes' '--enable-sysvsem=yes' '--with-config-file-path=/etc' '--no-create' --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10754edit=2 -- 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 ereg functions
Is it possible to remove the ereg functions? We have a strict policy to only use preg as they are more reliable and faster. So, I am not to happy that PHP is bloated with these ereg functions. Any thoughts? Uh, are you out of your mind? -Rasmus -- 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 #10892: error on PHP.INI distributed for win32
From: [EMAIL PROTECTED] Operating system: win32 PHP version: 4.0.5 PHP Bug Type: *Session related Bug description: error on PHP.INI distributed for win32 Dears, the file PHP.INI distributed with foxserv or within the php405 work correctly but Just i installed a PHP program for ecommerce (i.e. theexchangeproject.org; note I tried others with the same result), several errors occurs. I discovered that there is a little bug in: [Session] session.use_trans_sid=1 session.save_handler = files ; handler used to store/retrieve data session.save_path = /Temp; argument passed to save_handler infact the variable session.save_path is bad defined. There are not any notes about the win versio. Infact substituiting /Temp with c:/php/temp all work fine. Thank you for you attention, ALEX TUVERI -- Edit Bug report at: http://bugs.php.net/?id=10892edit=1 -- 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 ereg functions
That is why I am asking. Is there a core reason that the ereg functions have to be there? I could extend this to other functions as well of course. But this set in particular I have wondered about. Brian Moon -- dealnews.com, Inc. Makers of dealnews, dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Rasmus Lerdorf [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, May 16, 2001 2:19 AM Subject: Re: [PHP-DEV] removing ereg functions Is it possible to remove the ereg functions? We have a strict policy to only use preg as they are more reliable and faster. So, I am not to happy that PHP is bloated with these ereg functions. Any thoughts? Uh, are you out of your mind? -Rasmus -- 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 #10893: Failes to compile zend_hash.c:257: `LONG_MAX' undeclared
From: [EMAIL PROTECTED] Operating system: Redhat 6.2 - Linux 2.2.17 PHP version: 4.0.5 PHP Bug Type: Compile Failure Bug description: Failes to compile zend_hash.c:257: `LONG_MAX' undeclared Php 4.0.4pl worked fine. When upgrading to 4.0.5 I ran into this compile error. After I got this error i tried compiling 4.0.4pl1 and no problems. So I am suspecting it is has something to do w/ 4.0.5 CONFIG OPTIONS - ./configure --with-apache=../../../apache_1.3.19 --enable-track-vars --disable-debug --with-mysql COMPILER VOMIT- /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2 -c zend_hash.c zend_hash.c: In function `zend_hash_add_or_update': zend_hash.c:257: `LONG_MAX' undeclared (first use in this function) zend_hash.c:257: (Each undeclared identifier is reported only once zend_hash.c:257: for each function it appears in.) zend_hash.c: In function `zend_hash_del_key_or_index': zend_hash.c:502: `LONG_MAX' undeclared (first use in this function) zend_hash.c: In function `zend_hash_find': zend_hash.c:852: `LONG_MAX' undeclared (first use in this function) zend_hash.c: In function `zend_hash_exists': zend_hash.c:902: `LONG_MAX' undeclared (first use in this function) make[1]: *** [zend_hash.lo] Error 1 make[1]: Leaving directory `/usr/src/apache/modules/php/php-4.0.5/Zend' make: *** [all-recursive] Error 1 -- Edit Bug report at: http://bugs.php.net/?id=10893edit=1 -- 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 ereg functions
hm... That is why I am asking. Is there a core reason that the ereg functions have to be there? I could extend this to other functions as well of course. But this set in particular I have wondered about. maybe because some people are using them? ... Peter Petermann -- 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 ereg functions
That is why I am asking. Is there a core reason that the ereg functions have to be there? I could extend this to other functions as well of course. But this set in particular I have wondered about. 1) There was no PCRE library when I first added regex support to PHP. Henry Spencer's regex library, although not my initial choice, was chosen because that is what came bundled with Apache. 2) The ereg_* functions implement the Posix 1003.2 extended regular expression standard. The same regular expressions found in the Unix command line utils like grep, egrep and fgrep. The preg_* functions support the perverted Perl-style regular expressions. 3) Removing the ereg_* functions would cause a backward compatibility nightmare. Thousands, if not hundreds of thousands of scripts out there would have to be converted. 4) If you are using Apache you already have the library linked in anyway. Removing PHP support wouldn't save you any bloat. Not that this bloat is at all significant on any modern OS with shared pages. -Rasmus -- 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 #10874 Updated: getcwd() always return empty string.
ID: 10874 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: Directory function related Operating system: Linux Redhat7.0 PHP Version: 4.0.5 Description: getcwd() always return empty string. Ok. I tryed latest snapshot from http://snaps.php.net/ It doesn't have this bug. I recompiled 4.0.5 - it has bug. see difference: http://www2.osp.ru/~artem/t8/t8-dev.html http://www2.osp.ru/~artem/t8/t8-405.html Previous Comments: --- [2001-05-16 00:29:52] [EMAIL PROTECTED] I can't reproduce this either. Please try latest snapshot from http://snaps.php.net/ --Jani --- [2001-05-15 06:26:29] [EMAIL PROTECTED] Apache, static module. see result of this script ?php echo pwd: '.`pwd`.'br; echo getcwd: '.getcwd().'br; phpinfo(); ? on http://www2.osp.ru/~artem/t8.php --- [2001-05-15 05:55:59] [EMAIL PROTECTED] I can't reproduce this too. What SAPI are you using (Which webserver, and CGI or Module)? Derick --- [2001-05-15 05:48:48] [EMAIL PROTECTED] Cannot recreate this on any system with current CVS. --- [2001-05-15 05:42:36] [EMAIL PROTECTED] ?php echo '.getcwd().'; ? --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=10874 -- 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] PHP 4.0.6RC1 - Win32 build of php4apache fails
I rolled 4.0.6RC1. It is ready for testing.
http://www.php.net/~andi/php-4.0.6RC1.tar.gz
Please everyone take sometime to make sure this is release worthy :)
cgi version for win32 builds fine, apache module build gives errors:
F:\home\cvs-php\php-4.0.6RC1\sapi\apache\mod_php4.c(310) : error C2065:
'apache_globals' : undeclared identifier
F:\home\cvs-php\php-4.0.6RC1\sapi\apache\mod_php4.c(310) : error C2223:
left of '-in_request' must point to struct/union
The offending function:
static int php_apache_sapi_activate(SLS_D)
{
request_rec *r = ((request_rec *) SG(server_context));
/*
* For the Apache module version, this bit of code registers a
cleanup
* function that gets triggered when our request pool is destroyed.
* We need this because at any point in our code we can be
interrupted
* and that may happen before we have had time to free our memory.
* The php_request_shutdown function needs to free all outstanding
allocated
* memory.
*/
block_alarms();
register_cleanup(((request_rec *) SG(server_context))-pool, NULL,
php_apache_request_shutdown, php_request_shutdown_for_exec);
(line 310) AP(in_request)=1;
unblock_alarms();
/* Override the default headers_only value - sometimes GET
requests should actually only
* send headers.
*/
SG(request_info).headers_only = r-header_only;
return SUCCESS;
}
It misses the
APLS_FETCH();
at the beginning of the function, after adding this it builds fine.
Cheerio, Marc.
--
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 #8772 Updated: user level session storage fails when register_globals off
ID: 8772 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: *Session related Operating system: RH Linux 7.0 PHP Version: 4.0.5 Description: user level session storage fails when register_globals off Hi Guys, Well I installed PHP 4.0.5 hoping it would fix my problem with sessions and it still does not work! Any help from someone knowledgable on this issue would be nice since I reported this bug over 3 months ago. Thanks, Serge Previous Comments: --- [2001-03-04 07:09:10] [EMAIL PROTECTED] I would like to know if there is any news with regards to this bug? The workaround involves using register_globals on and I really don't like this aproach. Thanks, Serge --- [2001-02-22 18:39:01] [EMAIL PROTECTED] Steve Chadsey has reported that he has the same bug as me: His message follow. For the record, I am having the *exact* problem you describe. It's on a RedHat 6.2 system, kernel 2.4.1, PostgreSQL 7.0.3, Apache/1.3.17 (Unix) mod_perl/1.25 PHP/4.0.4pl1. With register_globals off, the session write function is never getting called. With register_globals on, it works fine. Do you think I should add a new bug report? Can I add a me too to your bug report? Thanks, -- Steve Chadsey [EMAIL PROTECTED] --- [2001-02-03 07:14:11] [EMAIL PROTECTED] Looks like someone else is having the same problem. See bug number 9002 Serge --- [2001-01-25 14:39:36] [EMAIL PROTECTED] Below are my php.ini settings and Virtual Host settings Serge # php.ini file [PHP] engine = On short_open_tag = On asp_tags= Off precision = 14 y2k_compliance = Off output_buffering= Off output_handler = implicit_flush = Off allow_call_time_pass_reference = Off ; Safe Mode safe_mode = Off safe_mode_exec_dir = safe_mode_allowed_env_vars = PHP_ safe_mode_protected_env_vars = LD_LIBRARY_PATH disable_functions = #zend_optimizer.optimization=15 #zend_extension=/usr/local/Zend/lib/ZendOptimizer.so zend_extension=/usr/local/Zend/lib/ZendDebugger.so ; Colors for Syntax Highlighting mode. Anything that's acceptable in font color=??? would work. highlight.string= #DD highlight.comment = #FF8000 highlight.keyword = #007700 highlight.bg= #FF highlight.default = #BB highlight.html = #00 ; Misc expose_php = Off ;;; ; Resource Limits ; ;;; max_execution_time = 60 memory_limit = 8M error_reporting = E_ALL ~E_NOTICE ~E_WARNING display_errors = On display_startup_errors = Off log_errors = Off track_errors= On ;error_prepend_string = font color=ff ;error_append_string = /font ;error_log = filename ;error_log = syslog warn_plus_overloading = Off ; ; Data Handling ; ; variables_order = GPCS register_globals= Off register_argc_argv = Off post_max_size = 8M gpc_order = GPC ; Magic quotes magic_quotes_gpc= Off magic_quotes_runtime= Off magic_quotes_sybase = Off ; automatically add files before or after any PHP document auto_prepend_file = auto_append_file= ; PHP's built-in default is text/html default_mimetype = text/html ;default_charset = iso-8859-1 ; ; Paths and Directories ; ; include_path= doc_root= user_dir= extension_dir = ./ enable_dl = On ; File Uploads ; file_uploads= On ;upload_tmp_dir = upload_max_filesize = 15M ;; ; Fopen wrappers ; ;; allow_url_fopen = On ;;; ; Module Settings ; ;;; [Syslog] define_syslog_variables = Off [mail function] SMTP= localhost sendmail_from = [EMAIL PROTECTED] sendmail_path = '/var/qmail/bin/qmail-inject -N' [Debugger] debugger.host = localhost debugger.port = 7869 debugger.enabled= False [Logging] ;logging.method= db ;logging.directory = /path/to/log/directory [Java] [SQL] sql.safe_mode = Off [ODBC] odbc.allow_persistent = On odbc.check_persistent =On
[PHP-DEV] Bug #10894: Problem with C include file
From: [EMAIL PROTECTED] Operating system: Mac OSX PHP version: 4.0.5 PHP Bug Type: *Install and Config Bug description: Problem with C include file Hi there, While compiling PHP on my Mac OSX box I came accross the following problem: The file: /php-4.0.5/main/internal_functions.c There is a block of code that looks like this: #include ext/mysql/php_mysql.hn#include ext/pcre/php_pcre.hn#include ext/posix/php_posix.hn#include ext/session/mod_mm.hn#include ext/session/php_session.hn#include ext/standard/php_standard.hn#include ext/xml/php_xml.h What it looks like has happened is that when this include file was generated there was supposed to be a '\n' between the #includes in the C code but only a 'n' was inserted, for now I fixed this manually, I don't know if this is OS specific, Just thought I would drop you a mail to let you know :O) Regards Kieran -- Edit Bug report at: http://bugs.php.net/?id=10894edit=1 -- 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 #8978 Updated: Add a 'readonly' possibility to the session module
ID: 8978
User Update by: Maxim Derkachev [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Feature/Change Request
Operating system:
PHP Version: 4.0.4pl1
Description: Add a 'readonly' possibility to the session module
just made a patch against the current sources (session.c and php_session.h).
*** php_session.h.orig Tue May 15 15:16:50 2001
--- php_session.h Tue May 15 15:23:26 2001
***
*** 96,100
--- 96,103
zend_bool define_sid;
zend_bool use_cookies;
+ int readonly;
} php_ps_globals;
+
+ #define SESS_READONLY 1
extern zend_module_entry session_module_entry;
*** session.c.orig Tue May 15 15:16:04 2001
--- session.c Wed May 16 11:54:31 2001
***
*** 526,529
--- 526,533
PLS_FETCH();
+ if (PS(readonly)) {
+ return;
+ }
+
if (!PG(register_globals)) {
if (!PS(http_session_vars)) {
***
*** 899,902
--- 903,911
zend_bool retval = SUCCESS;
+ if (PS(readonly)) {
+ php_error(E_WARNING, Trying to destroy readonly session);
+ return FAILURE;
+ }
+
if (PS(nr_open_sessions) == 0) {
php_error(E_WARNING, Trying to destroy uninitialized session);
***
*** 1265,1270
--- 1274,1297
PHP_FUNCTION(session_start)
{
+ pval **flag;
PSLS_FETCH();
+ if (ZEND_NUM_ARGS() 1)
+ WRONG_PARAM_COUNT;
+
+ if (ZEND_NUM_ARGS() == 0 ) {
+ PS(readonly) = 0;
+ }
+ if (ZEND_NUM_ARGS() == 1 zend_get_parameters_ex(1, flag) != FAILURE) {
+ convert_to_long_ex(flag);
+ if (((int) ((*flag)-value.lval)) == SESS_READONLY) {
+ PS(readonly) = 1;
+ }
+ else {
+ PS(readonly) = 0;
+ }
+ }
+
+
php_session_start(PSLS_C);
***
*** 1314,1317
--- 1341,1347
PSLS_FETCH();
+ if (PS(readonly))
+ return;
+
if (PS(nr_open_sessions) == 0)
RETURN_FALSE;
***
*** 1353,1356
--- 1383,1388
PSLS_FETCH();
+ REGISTER_LONG_CONSTANT(SESS_READ_ONLY, SESS_READONLY, CONST_CS);
+
php_rinit_session_globals(PSLS_C);
***
*** 1404,1407
--- 1436,1440
PS(module_number) = module_number;
REGISTER_INI_ENTRIES();
+ REGISTER_LONG_CONSTANT(SESS_READ_ONLY, SESS_READONLY, CONST_CS);
return SUCCESS;
}
Previous Comments:
---
[2001-01-29 06:21:31] Maxim Derkachev [EMAIL PROTECTED]
Just faced the fact that the possibility to call session 'readonly'
should be added.
For example, when somebody calls a framed pages where all
frames are php scripts that needs session variables. But in this
case only one of them should be allowed to write session state,
because every frame would write session state in an unpredictable order,
and variables registered/changed in one frame could be overwritten
by other frames, and that would definitely break an application.
I suggest session_start could take an optional READONLY flag to
disable write of the session data during the page shutdown.
The idea is similar to call page_close() on only one frame in a framed page in
PHPLib-based applications.
---
Full Bug description available at: http://bugs.php.net/?id=8978
--
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 #10895: Segmentation Fault
From: [EMAIL PROTECTED] Operating system: Sun Solaris 5.8 on Intel PHP version: 4.0.5 PHP Bug Type: *Session related Bug description: Segmentation Fault I had got Segmentation Faults using the sessions with PHP 4.05. After installing PHP 4.04pl1 the same code works fine. I use the session_start(),session_register(),session_unregister() functions. But i could not localize which of them causes the problems, i'd expect that it is session_unregister(). ./configure \ --with-mysql=/usr/local/mysql \ --with-apache=../apache_1.3.19 \ --enable-dbg=shared \ --with-ttf=/usr/local \ --with-gd \ --with-xml \ --with-zlib=/usr/local \ --with-jpeg-dir=/usr/local \ --enable-track-vars \ --enable-url-includes \ --disable-debug \ Claus -- Edit Bug report at: http://bugs.php.net/?id=10895edit=1 -- 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 #8978 Updated: Add a 'readonly' possibility to the session module
ID: 8978
User Update by: Maxim Derkachev [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Feature/Change Request
Operating system:
PHP Version: 4.0.4pl1
Description: Add a 'readonly' possibility to the session module
Forgot to include the batteries :)
After the patch above is applied, one could do:
session_start(SESS_READ_ONLY);
to start a readonly session.
Functions that supposed to write the session data (core session functions, not actual
savehandler functions) will be disabled.
On the other page, if session_start() is called without the SESS_READ_ONLY flag, one
could get the normal fully functional session, which will write the data. That would
allow to use session in framed pages, when one frame is allowed to change the session
data and another frames only read the data, and in many other cases. E.g. for me the
feature has become inevitable when I needed to write a support chat, which should read
session variables, but should not change them and, the most important, it should not
save them, because a client could browse other parts of the site (and this could
affect the sesson vars) while he is chatting with the support. Without the readonly
possibility, the new session variables could be easily rewrited by the chat script
with outdated values.
Previous Comments:
---
[2001-05-16 04:02:23] Maxim Derkachev [EMAIL PROTECTED]
just made a patch against the current sources (session.c and php_session.h).
*** php_session.h.orig Tue May 15 15:16:50 2001
--- php_session.h Tue May 15 15:23:26 2001
***
*** 96,100
--- 96,103
zend_bool define_sid;
zend_bool use_cookies;
+ int readonly;
} php_ps_globals;
+
+ #define SESS_READONLY 1
extern zend_module_entry session_module_entry;
*** session.c.orig Tue May 15 15:16:04 2001
--- session.c Wed May 16 11:54:31 2001
***
*** 526,529
--- 526,533
PLS_FETCH();
+ if (PS(readonly)) {
+ return;
+ }
+
if (!PG(register_globals)) {
if (!PS(http_session_vars)) {
***
*** 899,902
--- 903,911
zend_bool retval = SUCCESS;
+ if (PS(readonly)) {
+ php_error(E_WARNING, Trying to destroy readonly session);
+ return FAILURE;
+ }
+
if (PS(nr_open_sessions) == 0) {
php_error(E_WARNING, Trying to destroy uninitialized session);
***
*** 1265,1270
--- 1274,1297
PHP_FUNCTION(session_start)
{
+ pval **flag;
PSLS_FETCH();
+ if (ZEND_NUM_ARGS() 1)
+ WRONG_PARAM_COUNT;
+
+ if (ZEND_NUM_ARGS() == 0 ) {
+ PS(readonly) = 0;
+ }
+ if (ZEND_NUM_ARGS() == 1 zend_get_parameters_ex(1, flag) != FAILURE) {
+ convert_to_long_ex(flag);
+ if (((int) ((*flag)-value.lval)) == SESS_READONLY) {
+ PS(readonly) = 1;
+ }
+ else {
+ PS(readonly) = 0;
+ }
+ }
+
+
php_session_start(PSLS_C);
***
*** 1314,1317
--- 1341,1347
PSLS_FETCH();
+ if (PS(readonly))
+ return;
+
if (PS(nr_open_sessions) == 0)
RETURN_FALSE;
***
*** 1353,1356
--- 1383,1388
PSLS_FETCH();
+ REGISTER_LONG_CONSTANT(SESS_READ_ONLY, SESS_READONLY, CONST_CS);
+
php_rinit_session_globals(PSLS_C);
***
*** 1404,1407
--- 1436,1440
PS(module_number) = module_number;
REGISTER_INI_ENTRIES();
+ REGISTER_LONG_CONSTANT(SESS_READ_ONLY, SESS_READONLY, CONST_CS);
return SUCCESS;
}
---
[2001-01-29 06:21:31] Maxim Derkachev [EMAIL PROTECTED]
Just faced the fact that the possibility to call session 'readonly'
should be added.
For example, when somebody calls a framed pages where all
frames are php scripts that needs session variables. But in this
case only one of them should be allowed to write session state,
because every frame would write session state in an unpredictable order,
and variables registered/changed in one frame could be overwritten
by other frames, and that would definitely break an application.
I suggest session_start could take an optional READONLY flag to
disable write of the session data during the page shutdown.
The idea is similar to call page_close() on only one frame in a framed page in
PHPLib-based applications.
---
Full Bug description available at: http://bugs.php.net/?id=8978
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL
Re: [PHP-DEV] removing ereg functions
At 08:50 16/5/2001, Brian Moon wrote: Is it possible to remove the ereg functions? We have a strict policy to only use preg as they are more reliable and faster. So, I am not to happy that PHP is bloated with these ereg functions. Any thoughts? Wow, it's like a plague out there. :) No way. ereg() has got to be used by millions of code lines around the world. I don't see it being removed in this millennium. These functions can fit nicely into the lean-and-mean approach. Zeev -- 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 #10896: fgetcsv doesn't handle foreign characters properly
From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version: 4.0.4pl1
PHP Bug Type: Filesystem function related
Bug description: fgetcsv doesn't handle foreign characters properly
fgetcsv doesn't handle foreign characters properly.
For example if the csv file has following content:
Èína;2.1.2001;2-hý deò Nového roka
the comand $line = fgetcsv($fd, 4096, ;);
gets the array('na','2.1.2001','2-hý deò Nového roka').
(proper array is ('Èína','2.1.2001','2-hý deò Nového roka'), using the fgetsexplode
function works without problem:
$rec = fgets($fd, 4096);
$line=explode (;, $rec);
)
--
Edit Bug report at: http://bugs.php.net/?id=10896edit=1
--
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 #10302 Updated: odbc_tables()
ID: 10302
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: ODBC related
Operating system: winnt4sp6
PHP Version: 4.0.4pl1
Description: odbc_tables()
Update:
The same script works fine using the CGI interface.
If I select the reload page button on the browser, it works using ISAPI about 1 in 5
times!
Previous Comments:
---
[2001-05-16 02:51:32] [EMAIL PROTECTED]
I have just updated php to 4.0.5 with the same results.
I also added odbc_error() and odbc_errormsg() after the
'SORRY . I Cant't Get The Table Details' message, and they return empty stings.
Thanks
John
---
[2001-04-23 12:27:53] [EMAIL PROTECTED]
code example:-
?php
$dsn=php; // System DSN
$user=GUEST;
$passwd=;
$db = odbc_connect($dsn,$user,$passwd);
if(!$db) {
echo SORRY: could not connect to databasebr;
die();
}
//
// get table list
//
$table_list=array();
$result = odbc_tables($db);
if($result) {
$count=0;
// debug lines
echo odbc_num_rows($result) . Tables found br;
odbc_result_all($result);
// end debug
while(($report = odbc_fetch_row($result))) {
$row[$count] = odbc_result($result,3);
$count++;
}
if($count 0) {
sort($row);
for(reset($row);$table_list[]=current($row);next($row)) { }
} else {
echo SORRY. I Can't Get The Table Detailsbr;
die();
}
}
//-
// get field names
//-
if(!$tables)
$tables=$table_list[0];
$result = odbc_columns($db,,,$tables);
if($result) {
$row=array();
$count=0;
while(($report = odbc_fetch_row($result))) {
$row[$count] = odbc_result($result,4);
$count++;
}
if($count 0) {
sort($row);
for(reset($row);$columns[]=current($row);next($row)) {}
} else {
echo SORRY. I Can't Get The Field Detailsbr;
die();
}
}
odbc_close($db);
odbc_num_rows() returns a count of tables in the database,
odbc_results_all() returns no rows,
odbc_fetch_row() returns false.
---
[2001-04-18 21:37:34] [EMAIL PROTECTED]
can you please provide a sample script on how to reproduce this?
---
[2001-04-12 10:47:08] [EMAIL PROTECTED]
I think this may have been an issue in a previous release but I am still having it in
this version.
after calling odbc_tables() I can not get the results using odbc_fetch_row() or
odbc_result_all(), but odbc_num_rows() does return the number of tables in the
database.
The system is using the precomplied version downloaded from zend with the default
php.ini file. Oh and in ISAPI mode!
Thanks
---
Full Bug description available at: http://bugs.php.net/?id=10302
--
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] Latest commit -- depreciation of call_user_method()
At 01:40 15/5/2001, Sterling Hughes wrote: Sure, yeah. But as a note, other big projects with huge user bases break compatibility as well, Perl, Apache, Python, to name three. It doesn't mean it's a good idea. And in its own way, C, is constantly breaking compat, the amount of times I've had to upgrade programs i've written, because a library changes is countless... Well, C's been pretty darned stable along the years, since it was ANSI'fied. C++ was a moving target. I don't recall having to make any significant changes in PHP's fairly-large codebase (as well as other codebases I was working on along the years) due to standard changes, except for, perhaps, the inline issues. I definitely wouldn't consider this to be a precedence for making downwards incompatible changes. On the other hand, I really don't like the bloat either. So, what should be done? In my opinion, the approach of adding E_NOTICE notifications to functions doesn't cut it; It won't significantly improve the situation. I think we should go in a different path (or an 'extended' path) - IMHO, the best approach would be adding some sort of a 'LEAN_AND_MEAN' mode to PHP's build. When built in this mode, bloat code will be #define'd away, or displayed as 'deprecated' in a similar manner to the way warn_not_available works. That gives everyone almost everything - people who care about the bloat (like me) will build it in LEAN_AND_MEAN mode, hosting companies or legacy sites, who care most about having their code go on working with minimum hassle - won't mind the added bloat. If kept closely documented, people who care enough about the bloat will be able to go through the checklist, make sure their sites are compatible with it, and turn this mode on. well, you can't have your cake and eat it too. No need to get into metaphores - I'm suggesting a very specific solution. What's the cake and who's eating it, I don't know :) (did I say this before when talking about backwards compat, AHH, hey Zeev, is PHP an OO language? ;) I'm not sure how it's related to downwards compatibility... Well, what I intended to do was mark it with an E_NOTICE for this release and if no one complained with my latest commit, redo the call_user_method*() documentation as well as a big ass news entry. Next release, bump up the level to E_WARNING, and add a nice sized NEWS entry about that. Finally, third release, say buh-bye to good old call_user_method, and replace it with a new function, warn_depreciated. Bare in mind that many people don't upgrade on every release. I'd argue even that most people don't, and only upgrade every 2 or 3 releases, that is, if they upgrade at all. So for them, this entire process will be a single and swift blow in the face, despite your efforts. Also bare in mind that a very large percentage of the developers don't *want* to be forced to change their code, and consider it to be a misfeature in the language if it breaks downwards compatibility in between releases, regardless of whether they get a clear notification about it or not. However, you have a very good point, ISP's will be pissed if we drastically change the syntax. They're pissed even if we slightly change the syntax, too, as a matter of fact. It's the small downwards compatibility breaks that make them say the hell with it, I'm not upgrading. And your solution seems good, I'd just do the reverse (semantically speaking), so instead, what I think we should do is have a --enable-backwards-compat mode. This mode would be for ISP's and people who need the bug fixes, etc. in new PHP releases, but don't want to upgrade their scripts. So, when deprecating a feature, the following is employed: minor release 1: non backwards compat mode php_error(E_WARNING, DEPRECATED FEATURE BUM!); minor release 2: now the function warn_deprecated replaces the deprecated function in non backwards compat mode, backwards compat mode is the only place the function is no longer present. The function code is moved to php4/legacy. I haven't thought out my opinion on how the deprecation process should be exactly, whether it should happen in minor or major releases only, and whether it should be on or off by default. As always, the first step would be implementing this mechanism and streamlining it. We can figure out the small details later. Zeev -- 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 #10897: Createimage
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.0.5 PHP Bug Type: *Function Specific Bug description: Createimage Can you tell me to creat a Gif image but in PHP4.05 not support CreateImageFromGIF? Do you give me some codes to create a GIF image ?. -- Edit Bug report at: http://bugs.php.net/?id=10897edit=1 -- 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 #10897 Updated: Createimage
ID: 10897 Updated by: rasmus Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: *Function Specific Operating system: PHP Version: 4.0.5 Assigned To: Comments: PHP 4.0.5 supports CreateImageFromGif if you compile PHP against a version of the GD library which supports GIF. Previous Comments: --- [2001-05-16 04:41:16] [EMAIL PROTECTED] Can you tell me to creat a Gif image but in PHP4.05 not support CreateImageFromGIF? Do you give me some codes to create a GIF image ?. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10897edit=2 -- 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 #10898: is_dir filetype return wrong values
From: [EMAIL PROTECTED] Operating system: Win ME Win NT 4.0 PHP version: 4.0.5 PHP Bug Type: Filesystem function related Bug description: is_dir filetype return wrong values Hello, I'm running php 4.0.5 on my win ME Win NT 4.0 and I have experienced 2 functions returning the wrong values. I don't know if this bug is allready reported. the is_dir() allways returns false except for . .. the filetype() allways returns dir -- Edit Bug report at: http://bugs.php.net/?id=10898edit=1 -- 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] Create a fifo special file
Hello, Could you give me some examples of use for posix_mkfifo ?? I have to send and catch messages to a process (C librairy) on my server. I think i have to use Pipe, but this function isn't commented... Thank's all :) Sebastien ROUSSEAU -- 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: [PHP-QA] Re: [PHP-DEV] PHP 4.0.6RC1 ready for testing
At 22:39 15.05.2001 +0300, Andi Gutmans wrote: I can do a basic build but I think Daniel Beulshausen might be able to do a more complete build with a lot of Windows extensions. Or is there anyone else? i've uploaded a build at http://www.php4win.de/php-4.0.6-rc1.exe i'd appreciate if it could be mirrored somewhere, as it's going to be deleted from the server in a few days. daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.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] Bug #10893 Updated: Failes to compile zend_hash.c:257: `LONG_MAX' undeclared
ID: 10893 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Compile Failure Operating system: PHP Version: 4.0.5 Assigned To: Comments: There is something wrong with your sources. Get a fresh package, unpack / untar it and try again. --Jani Previous Comments: --- [2001-05-16 03:38:39] [EMAIL PROTECTED] Php 4.0.4pl worked fine. When upgrading to 4.0.5 I ran into this compile error. After I got this error i tried compiling 4.0.4pl1 and no problems. So I am suspecting it is has something to do w/ 4.0.5 CONFIG OPTIONS - ./configure --with-apache=../../../apache_1.3.19 --enable-track-vars --disable-debug --with-mysql COMPILER VOMIT- /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2 -c zend_hash.c zend_hash.c: In function `zend_hash_add_or_update': zend_hash.c:257: `LONG_MAX' undeclared (first use in this function) zend_hash.c:257: (Each undeclared identifier is reported only once zend_hash.c:257: for each function it appears in.) zend_hash.c: In function `zend_hash_del_key_or_index': zend_hash.c:502: `LONG_MAX' undeclared (first use in this function) zend_hash.c: In function `zend_hash_find': zend_hash.c:852: `LONG_MAX' undeclared (first use in this function) zend_hash.c: In function `zend_hash_exists': zend_hash.c:902: `LONG_MAX' undeclared (first use in this function) make[1]: *** [zend_hash.lo] Error 1 make[1]: Leaving directory `/usr/src/apache/modules/php/php-4.0.5/Zend' make: *** [all-recursive] Error 1 --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10893edit=2 -- 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: [PHP-QA] Re: [PHP-DEV] PHP 4.0.6RC1 ready for testing
hiho, i've uploaded a build at http://www.php4win.de/php-4.0.6-rc1.exe i'd appreciate if it could be mirrored somewhere, as it's going to be deleted from the server in a few days. daniel maybe this could be put to: phpweb/distributions/unsupported/ if this is ok, i could put it there... just tell me to do so.. Peter -- 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 #10898 Updated: is_dir filetype return wrong values
ID: 10898 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Filesystem function related Operating system: PHP Version: 4.0.5 Assigned To: Comments: Please provide a short script so that we can reproduce it. Derick Previous Comments: --- [2001-05-16 05:44:07] [EMAIL PROTECTED] Hello, I'm running php 4.0.5 on my win ME Win NT 4.0 and I have experienced 2 functions returning the wrong values. I don't know if this bug is allready reported. the is_dir() allways returns false except for . .. the filetype() allways returns dir --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10898edit=2 -- 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 #10899: xmldocfile produces fatal error
From: [EMAIL PROTECTED] Operating system: linux 2.4.4 PHP version: 4.0 Latest CVS (2001-05-16) PHP Bug Type: DOM XML related Bug description: xmldocfile produces fatal error $doc = xmldocfile(config.xml); produces Fatal error: Underlying object missing in /usr/local/apache/htdocs/test/xml.php on line 13 in PHP-4.0.6RC1 config.xml is ?xml version=1.0? test one type=blabla/one two type=foo/ /test if i make a sting out of it and then $doc = xmldoc($xml); it works -- Edit Bug report at: http://bugs.php.net/?id=10899edit=1 -- 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 #9009 Updated: build problem with informix esql 9.30 and iODBC 2.50.3
ID: 9009 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: Compile Failure Operating system: Linux 2.2.16 (SuSE 7.0) PHP Version: 4.0.5 Description: build problem with informix esql 9.30 and iODBC 2.50.3 tried to compile php-4.0.5 with config: export INFORMIXDIR=/opt/informix export PATH=$PATH:/opt/informix/bin:/opt/informix/lib/esql ./configure --with-apxs=/opt/apache/bin/apxs --with-config-file-path=/opt/apache/conf --enable-debug=yes --with-xml --with-dbase --enable-bcmath --with-bz2 --enable-wddx --without-mysql --with-iodbc=/opt/iodbc --with-informix=/opt/informix ... make: zend_language_scanner.c:5546: warning: `yy_fatal_error' defined but not used zend_language_scanner.c:5531: warning: `yy_top_state' defined but not used zend_ini_scanner.c: In function `ini_lex': zend_ini_scanner.c:818: warning: label `find_rule' defined but not used zend_ini_scanner.c: At top level: zend_ini_scanner.c:1840: warning: `yy_flex_realloc' defined but not used zend_ini_scanner.c:1323: warning: `yyunput' defined but not used zend_hash.c: In function `zend_hash_compare': zend_hash.c:1145: warning: `p2' might be used uninitialized in this function zend_builtin_functions.c:704: warning: `copy_import_use_file' defined but not used zend_ini.c:311: warning: `zend_ini_displayer_cb' defined but not used main.c: In function `php_hash_environment': main.c:984: warning: `dummy_track_vars_array' might be used uninitialized in this function In file included from /opt/iodbc/include/sql.h:38, from /opt/iodbc/include/isql.h:32, from /tmp/php-4.0.5/ext/odbc/php_odbc.h:95, from internal_functions.c:36: /opt/iodbc/include/sqltypes.h:83: parse error before `0' In file included from /opt/iodbc/include/isql.h:32, from /tmp/php-4.0.5/ext/odbc/php_odbc.h:95, from internal_functions.c:36: /opt/iodbc/include/sql.h:230: parse error before `0' /opt/iodbc/include/sql.h:240: parse error before `0' /opt/iodbc/include/sql.h:255: parse error before `0' /opt/iodbc/include/sql.h:263: parse error before `0' /opt/iodbc/include/sql.h:284: parse error before `0' /opt/iodbc/include/sql.h:294: parse error before `0' /opt/iodbc/include/sql.h:303: parse error before `0' In file included from /opt/iodbc/include/isqlext.h:32, from /tmp/php-4.0.5/ext/odbc/php_odbc.h:96, from internal_functions.c:36: /opt/iodbc/include/sqlext.h:1131: parse error before `0' /opt/iodbc/include/sqlext.h:1196: parse error before `0' /opt/iodbc/include/sqlext.h:1207: parse error before `0' /opt/iodbc/include/sqlext.h:1218: parse error before `0' /opt/iodbc/include/sqlext.h:1231: parse error before `0' /opt/iodbc/include/sqlext.h:1243: parse error before `0' /opt/iodbc/include/sqlext.h:1251: parse error before `0' /opt/iodbc/include/sqlext.h:1263: parse error before `0' /opt/iodbc/include/sqlext.h:1287: parse error before `0' /opt/iodbc/include/sqlext.h:1305: parse error before `0' /opt/iodbc/include/sqlext.h:1322: parse error before `0' /opt/iodbc/include/sqlext.h:1331: parse error before `0' /opt/iodbc/include/sqlext.h:1342: parse error before `0' /opt/iodbc/include/sqlext.h:1357: parse error before `0' /opt/iodbc/include/sqlext.h:1371: parse error before `0' make[2]: *** [internal_functions.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 Hope that helps, Martin Previous Comments: --- [2001-05-11 15:21:08] [EMAIL PROTECTED] 1) Do try to do this with the most recent version of PHP 2) please add a copy of your configure line --- [2001-01-30 15:37:01] [EMAIL PROTECTED] make fails with Informix-ESQL and iODBC configured both. when only one of both modules is configured, make works. there seem's to be a conflict with libtool and two included sql.h-files error-message: /bin/sh /tmp/php-4.0.4/libtool --silent --mode=compile gcc -I. -I/tmp/php-4.0.4/main -I/tmp/php-4.0.4/main -I/tmp/php-4.0.4 -I/opt/apache/include -I/tmp/php-4.0.4/Zend -I/opt/informix/incl/esql -I/opt/iodbc/include -I/tmp/php-4.0.4/TSRM -DLINUX=2 -DUSE_HSREGEX -DUSE_EXPAT -g -O2 -I/opt/informix/incl/esql -c internal_functions.c In file included from /tmp/php-4.0.4/ext/odbc/php_odbc.h:95, from internal_functions.c:37: /opt/iodbc/include/sql.h:197: parse error before `SQL_API' /opt/iodbc/include/sql.h:198: parse error before `henv' /opt/iodbc/include/sql.h:199: warning: data definition has no type or storage class ... in iodbc/include/sql.h: 197: SQLRETURN SQL_API SQLAllocConnect ( SQLHENV henv SQLHDBC FAR * phdbc); SQLRETURN seems to be defined in informix/sql.h, that is included before iodbc/sql.h a workaround is to change the includes in php_odbc.h:95,96
[PHP-DEV] issues about domxml in 4.0.6
Hello As mentioned in bug #9896 the api for domxml seems to has changed a lot... it's now almost impossible to write code with domxml which works in 4.0.5 and 4.0.6. for example $root-children() returns a completely different Array (tagname instead of name and so on...). Does this make sense for a minor-update? And all the domxml function still just produce a segfault on 4.0.6. if this is not supported anymore, fine ($root-children() instead of domxml_children($root) works also in 4.0.5), but i'd prefer a fatal error instead of a segfault :) Maybe I have to live with all these api-changes and as soon as all our servers have 4.0.6, it won't be a problem for me. But I think i'm not the only one which disturbs that a little bit. chregu -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] off...+41 1 240 2304 icq...4196137 -- 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: AW: AW: [PHP-DEV] arrays
Acknowledged. But IMO the arrays will be either clearly continous or clearly associative/non-continous in 99.2% of the cases (Zeev statistics applied). I think it's fine to keep treating an array as non-continous if there has ever been holes or string keys in it. - Stig [Zeev Suraski [EMAIL PROTECTED]] It doesn't necessarily mean having to scrap the whole idea, just that we'd actually have to count elements, instead of just flagging. I'll try to think if there are any problems with this approach. Zeev At 02:57 15/5/2001, Andrei Zmievski wrote: At 02:51 AM 5/15/01 +0300, Zeev Suraski wrote: Ok, if we humor ourselves with this feature... What kind of behavior would you expect if a key gets deleted, and there are no longer associative members in the array? Good point... any time savings on the extension side would be negated if the engine had to check whether the array is fully associative on each operation. -Andrei -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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: [PHP-QA] Re: [PHP-DEV] PHP 4.0.6RC1 ready for testing
At 11:59 16/05/2001 +0200, Daniel Beulshausen wrote: At 22:39 15.05.2001 +0300, Andi Gutmans wrote: I can do a basic build but I think Daniel Beulshausen might be able to do a more complete build with a lot of Windows extensions. Or is there anyone else? i've uploaded a build at http://www.php4win.de/php-4.0.6-rc1.exe i'd appreciate if it could be mirrored somewhere, as it's going to be deleted from the server in a few days. daniel *** I just downloaded it and got some warning about a missing MSVCR70.dll : it seems to me that previous discussions elsewhere stated that this DLL is quite new, like a .NET thing... Sounds like libtool-1.4 on Debian to me =8\ hellekin -- 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: [PHP-QA] Re: [PHP-DEV] PHP 4.0.6RC1 ready for testing
I can do a basic build but I think Daniel Beulshausen might be able to do a more complete build with a lot of Windows extensions. Or is there anyone else? i've uploaded a build at http://www.php4win.de/php-4.0.6-rc1.exe i'd appreciate if it could be mirrored somewhere, as it's going to be deleted from the server in a few days. *** I just downloaded it and got some warning about a missing MSVCR70.dll : it seems to me that previous discussions elsewhere stated that this DLL is quite new, like a .NET thing... Sounds like libtool-1.4 on Debian to me =8\ hm.. tested it here on a fresh installed Win98 box, i dont have the file you mentioned, but there was no error!? Peter.. -- 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: [PHP-QA] Re: [PHP-DEV] PHP 4.0.6RC1 ready for testing
tested it here on a fresh installed Win98 box, i dont have the file you mentioned, but there was no error!? tested it on win2k too, no problems at all... Peter -- 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] Latest commit -- depreciation of call_user_method()
On Wed, 16 May 2001, Zeev Suraski wrote: Also bare in mind that a very large percentage of the developers don't *want* to be forced to change their code, and consider it to be a Who's forcing anybody to update anyway? misfeature in the language if it breaks downwards compatibility in between releases, regardless of whether they get a clear notification about it or not. It seems like everybody just ignores my emails..oh well. So I can rant again. :-p Have you ever heard that you can also change that number in the middle? 4.0.6 This one^ It can be something else than an ellipse called zero..it can even be a number 1!!! Whoa! Never thougth about that?! And maybe, just MAYBE then these people (who you seem to think of as complete idiots) would READ the NEWS file? Or e.g. RELEASE_NOTES ? Or is that number in the middle reserved for something special? Something the 'group' only know of and don't want to tell us lower class people? Maybe the 'group' could take their thumbs out of their asses and start DOING something? And maybe they could start listening to new ideas for once and a while. Or is the 'group' nowadays only Zeev/Andi ? It would be really nice to hear from the other members of the 'group' also as it really seems like the only ones speaking for it are Zeev/Andi.. Or could someone please define the function of this mysterious 'group' ? (And please, someone else than Zeev/Andi.. :) --Jani -- 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] issues about domxml in 4.0.6
On Wed, 16 May 2001, Christian Stocker wrote: As mentioned in bug #9896 the api for domxml seems to has changed a lot... it's now almost impossible to write code with domxml which works in 4.0.5 and 4.0.6. for example $root-children() returns a completely different Array (tagname instead of name and so on...). Does this make sense for a minor-update? No, it does not make any sense. Just curious..what would you think the version number change should be? So that it would tell you that there has been major changes? --Jani -- 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: [PHP-QA] Re: [PHP-DEV] PHP 4.0.6RC1 ready for testing
At 12:44 16.05.2001 +0200, Hellekin O. Wolf wrote: At 11:59 16/05/2001 +0200, Daniel Beulshausen wrote: At 22:39 15.05.2001 +0300, Andi Gutmans wrote: I can do a basic build but I think Daniel Beulshausen might be able to do a more complete build with a lot of Windows extensions. Or is there anyone else? i've uploaded a build at http://www.php4win.de/php-4.0.6-rc1.exe i'd appreciate if it could be mirrored somewhere, as it's going to be deleted from the server in a few days. daniel *** I just downloaded it and got some warning about a missing MSVCR70.dll : it seems to me that previous discussions elsewhere stated that this DLL is quite new, like a .NET thing... Sounds like libtool-1.4 on Debian to me =8\ hellekin that the openssl extension... just copy msvcrt.dll to msvcr70.dll, i didn't had the time to investigate at this. i'll have a look at it before the 4.0.6 release. daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.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] Bug #8638 Updated: PHP handles permission problems ungracefully rather than letting Apache do it
ID: 8638
User Update by: [EMAIL PROTECTED]
Status: Closed
Bug Type: Apache related
Operating system: Linux 2.2.17
PHP Version: 4.0.5
Description: PHP handles permission problems ungracefully rather than letting Apache
do it
That's a complete red herring; if file perms prevent your
script from even being read, it can't get as far as calling
set_error_handler().
However, after some further digging, I have discovered a
workaround; if you set auto_prepend_file in your php.ini
file, and call set_error_handler in that, it will be
triggered when the error above is generated. And if you put
code in it like:
if (($level == E_WARNING) ($file == Unknown)
($line == 0)) {
header(Location: /path/to/errordocument.html);
exit;
}
then this will emulate Apache's normal behaviour when it
finds a file with bad permissions.
It's only a workaround, but as no-one seems interested in
fixing the underlying problem, it'll have to do.
Previous Comments:
---
[2001-05-16 02:47:05] [EMAIL PROTECTED]
RTFM:
http://www.php.net/manual/en/function.set-error-handler.php
---
[2001-05-08 09:17:25] [EMAIL PROTECTED]
Still happens with php 4.0.5.
---
[2001-04-02 05:07:42] [EMAIL PROTECTED]
Yes, still happens with php4.04pl1.
---
[2001-03-31 08:08:34] [EMAIL PROTECTED]
Does it still happen? IIRC it was fixed.
---
[2001-01-10 10:31:13] [EMAIL PROTECTED]
I'm using Apache 1.3 with the config line:
AddType application/x-httpd-php php
When the permissions on any .php file are not set correctly for Apache to read them,
the error:
Warning: Failed opening '/path/to/page.php' for inclusion
(include_path='/path/to/phplib') in Unknown on line 0
appears.
The same problem still occurs with include_path='.:/path/to/phplib' in php.ini.
This is user-hostile - what ought to happen would be that Apache's normal 403 error
mechanism should be invoked.
---
The remainder of the comments for this report are too long. To view the rest of the
comments, please view the bug report online.
Full Bug description available at: http://bugs.php.net/?id=8638
--
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 #10874 Updated: getcwd() always return empty string.
ID: 10874 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Directory function related Operating system: PHP Version: 4.0.5 Assigned To: Comments: Ok, so it fixed then. Derick Previous Comments: --- [2001-05-16 03:46:25] [EMAIL PROTECTED] Ok. I tryed latest snapshot from http://snaps.php.net/ It doesn't have this bug. I recompiled 4.0.5 - it has bug. see difference: http://www2.osp.ru/~artem/t8/t8-dev.html http://www2.osp.ru/~artem/t8/t8-405.html --- [2001-05-16 00:29:52] [EMAIL PROTECTED] I can't reproduce this either. Please try latest snapshot from http://snaps.php.net/ --Jani --- [2001-05-15 06:26:29] [EMAIL PROTECTED] Apache, static module. see result of this script ?php echo pwd: '.`pwd`.'br; echo getcwd: '.getcwd().'br; phpinfo(); ? on http://www2.osp.ru/~artem/t8.php --- [2001-05-15 05:55:59] [EMAIL PROTECTED] I can't reproduce this too. What SAPI are you using (Which webserver, and CGI or Module)? Derick --- [2001-05-15 05:48:48] [EMAIL PROTECTED] Cannot recreate this on any system with current CVS. --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10874edit=2 -- 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 #10900: error in Makefile.in
From: [EMAIL PROTECTED] Operating system: Debian GNU/Linux PHP version: 4.0 Latest CVS (2001-05-16) PHP Bug Type: GD related Bug description: error in Makefile.in Hi, there is a bug in ext/gd/Makefile.in, that when gd is compiled as shared DSO extension doesn't add necessary library dependencies LTLIBRARY_SHARED_LIBADD = $(GD_LFLAGS) $(GD_LIBS) should be LTLIBRARY_SHARED_LIBADD = $(GD_SHARED_LIBADD) This is 4.0.6RC1, could the fix go into 4.0.6? Thanks -- Edit Bug report at: http://bugs.php.net/?id=10900edit=1 -- 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] issues about domxml in 4.0.6
On Wed, 16 May 2001, Jani Taskinen wrote: On Wed, 16 May 2001, Christian Stocker wrote: As mentioned in bug #9896 the api for domxml seems to has changed a lot... it's now almost impossible to write code with domxml which works in 4.0.5 and 4.0.6. for example $root-children() returns a completely different Array (tagname instead of name and so on...). Does this make sense for a minor-update? No, it does not make any sense. Just curious..what would you think the version number change should be? So that it would tell you that there has been major changes? i think, 4.1 would make me to have a look, if there were some api-changes. but not 4.0.5 to 4.0.6... chregu -- 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 #10900 Updated: error in Makefile.in
ID: 10900 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: GD related Operating system: PHP Version: 4.0 Latest CVS (2001-05-16) Assigned To: Comments: If it's in RC1, then it will be in the 4.0.6 Release. Derick Previous Comments: --- [2001-05-16 07:54:46] [EMAIL PROTECTED] Hi, there is a bug in ext/gd/Makefile.in, that when gd is compiled as shared DSO extension doesn't add necessary library dependencies LTLIBRARY_SHARED_LIBADD = $(GD_LFLAGS) $(GD_LIBS) should be LTLIBRARY_SHARED_LIBADD = $(GD_SHARED_LIBADD) This is 4.0.6RC1, could the fix go into 4.0.6? Thanks --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10900edit=2 -- 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 #10900 Updated: error in Makefile.in
Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: GD related Operating system: PHP Version: 4.0 Latest CVS (2001-05-16) Assigned To: Comments: If it's in RC1, then it will be in the 4.0.6 Release. First, you have not fixed the bug. Hence, closing the bug report was inappropiate. Second, the fix cannot affect ordinary users and therefore can be put into 4.0.6, even without further RCs. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- 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: [PHP-QA] Re: [PHP-DEV] PHP 4.0.6RC1 ready for testing
On Wed, May 16, 2001 at 12:44:39PM +0200 , Hellekin O. Wolf wrote:
quite new, like a .NET thing... Sounds like libtool-1.4 on Debian to me =8\
yup, but works mostly OK. Some glitches in getting libraries out of the main
binary, when GD, IMAP, SABLOT are compiled as DSO.
I'll probably upload it today
Petr Cech
--
Debian GNU/Linux maintainer - www.debian.{org,cz}
[EMAIL PROTECTED]
Those who don't understand Unix are condemned to reinvent it, poorly.
--
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 #10580 Updated: Access Violation using ADODB
ID: 10580
User Update by: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: COM related
Operating system: Win2k
PHP Version: 4.0.6-dev (dated 16-May-2001)
Description: Access Violation using ADODB
Bug reopened, CVS dated 16 May 2001,
message when accessing database:
PHP has encountered an Access Violation at 011CD614
Previous Comments:
---
[2001-05-08 20:12:03] [EMAIL PROTECTED]
works here.
the only mistake i found was, that if either the connect string or the query was wrong
$conn-execute() returned a nullpointer instead of a valid recordset.
this only produced a warning so there was a nullpointer exception at the first attempt
to access $rs-...
now i produce an error (unfortunatelly this causes the script to stop).
i'll fix this in the code and switch back to a warning, but i think it's ok for now.
---
[2001-05-08 19:18:07] [EMAIL PROTECTED]
Here is a code snippet for testing ADODB:
?php
define (DSN_USER, sa);
define (DSN_PWD, );
define (DB_SERVERNAME, localhost);
define (DATABASENAME, Northwind);
define (OLEDB_CONNECTION_STRING, Provider=SQLOLEDB; Data Source=.DB_SERVERNAME.;
Initial Catalog=.DATABASENAME.; User ID=.DSN_USER.; Password=.DSN_PWD);
$conn = new COM(ADODB.Connection) or die(Cannot start ADO);
$conn-Open(OLEDB_CONNECTION_STRING);
$command = SELECT * from employees;
$rs = $conn-Execute($command); // Recordset
$num_columns = $rs-Fields-Count();
$this-set_arr($num_columns);
for ($i=0; $i $num_columns; $i++) {
$fld[$i] = $rs-Fields($i);
}
$rowcount = 0;
while (!$rs-EOF) {
for ($i=0; $i $num_columns; $i++) {
$arr[$i][$rowcount] = $fld[$i]-value;
}
$rowcount++;// increments rowcount
$rs-MoveNext();
}
$rs-Close();
$conn-Close();
$rs = NULL;
$conn = NULL;
?
This produces the error: PHP has encountered an Access Violation at 2474FF04
You can also produce an Access Violation by trying to use MSXML Parser 3.0,
and by calling the loadXML() method.
I downloaded php 4.0.6-dev [2001-05-04] build from
php4win32.sourceforge.net/releases/php-4.0.6-dev-20010504.exe
---
[2001-05-08 16:30:55] [EMAIL PROTECTED]
could you provide a short snippet, i can't reproduce this.
are you using the cgi or the isapi version ?
---
[2001-05-04 22:54:14] [EMAIL PROTECTED]
Same bug, access violation using ADODB and MSXML Parser,
but using a 4.0.6 build, dated 2001-05-04.
---
[2001-05-04 11:29:31] [EMAIL PROTECTED]
This is now fixed in CVS. Fix will be in 4.0.6.
--Jani
---
The remainder of the comments for this report are too long. To view the rest of the
comments, please view the bug report online.
Full Bug description available at: http://bugs.php.net/?id=10580
--
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 #10898 Updated: is_dir filetype return wrong values
ID: 10898
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Filesystem function related
Operating system: Win ME Win NT 4.0
PHP Version: 4.0.5
Description: is_dir filetype return wrong values
A little script that should echo alle filetypes of all files in any subdir of the
parent provided.
Now I use opendir to test wether the file is a dir, but this isn't a good solution, is
it?
The is_dir() allways returns false
the filetype() allwyas returns dir
?php
function getFileInfo($parent)
{
$handle = opendir($parent);
while ($file = readdir($handle))
{
$filelist[]=$file ;
}
reset($filelist);
while(list(,$f)=each ($filelist))
{
if ($f!=. $f!=..)
{
if(is_dir($f))
{
getFileInfo($f);
}
else
{
echo filetype($f);
}
}
}
}
getFileInfo(c:\data\pdf);
?
Previous Comments:
---
[2001-05-16 06:23:07] [EMAIL PROTECTED]
Please provide a short script so that we can reproduce it.
Derick
---
[2001-05-16 05:44:07] [EMAIL PROTECTED]
Hello,
I'm running php 4.0.5 on my win ME Win NT 4.0 and I have experienced 2 functions
returning the wrong values. I don't know if this bug is allready reported.
the is_dir() allways returns false except for . ..
the filetype() allways returns dir
---
Full Bug description available at: http://bugs.php.net/?id=10898
--
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 #10580 Updated: Access Violation using ADODB
ID: 10580
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: COM related
Operating system: Win2k
PHP Version: 4.0.7-dev (dated 16-May-2001)
Description: Access Violation using ADODB
COM broken in PHP version 4.0.7-dev
Previous Comments:
---
[2001-05-16 08:34:57] [EMAIL PROTECTED]
Bug reopened, CVS dated 16 May 2001,
message when accessing database:
PHP has encountered an Access Violation at 011CD614
---
[2001-05-08 20:12:03] [EMAIL PROTECTED]
works here.
the only mistake i found was, that if either the connect string or the query was wrong
$conn-execute() returned a nullpointer instead of a valid recordset.
this only produced a warning so there was a nullpointer exception at the first attempt
to access $rs-...
now i produce an error (unfortunatelly this causes the script to stop).
i'll fix this in the code and switch back to a warning, but i think it's ok for now.
---
[2001-05-08 19:18:07] [EMAIL PROTECTED]
Here is a code snippet for testing ADODB:
?php
define (DSN_USER, sa);
define (DSN_PWD, );
define (DB_SERVERNAME, localhost);
define (DATABASENAME, Northwind);
define (OLEDB_CONNECTION_STRING, Provider=SQLOLEDB; Data Source=.DB_SERVERNAME.;
Initial Catalog=.DATABASENAME.; User ID=.DSN_USER.; Password=.DSN_PWD);
$conn = new COM(ADODB.Connection) or die(Cannot start ADO);
$conn-Open(OLEDB_CONNECTION_STRING);
$command = SELECT * from employees;
$rs = $conn-Execute($command); // Recordset
$num_columns = $rs-Fields-Count();
$this-set_arr($num_columns);
for ($i=0; $i $num_columns; $i++) {
$fld[$i] = $rs-Fields($i);
}
$rowcount = 0;
while (!$rs-EOF) {
for ($i=0; $i $num_columns; $i++) {
$arr[$i][$rowcount] = $fld[$i]-value;
}
$rowcount++;// increments rowcount
$rs-MoveNext();
}
$rs-Close();
$conn-Close();
$rs = NULL;
$conn = NULL;
?
This produces the error: PHP has encountered an Access Violation at 2474FF04
You can also produce an Access Violation by trying to use MSXML Parser 3.0,
and by calling the loadXML() method.
I downloaded php 4.0.6-dev [2001-05-04] build from
php4win32.sourceforge.net/releases/php-4.0.6-dev-20010504.exe
---
[2001-05-08 16:30:55] [EMAIL PROTECTED]
could you provide a short snippet, i can't reproduce this.
are you using the cgi or the isapi version ?
---
[2001-05-04 22:54:14] [EMAIL PROTECTED]
Same bug, access violation using ADODB and MSXML Parser,
but using a 4.0.6 build, dated 2001-05-04.
---
The remainder of the comments for this report are too long. To view the rest of the
comments, please view the bug report online.
Full Bug description available at: http://bugs.php.net/?id=10580
--
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 #10901: mssql.min_error_severity or mssql.min_message_severity have no effect
From: [EMAIL PROTECTED] Operating system: Win2k Server SP1 PHP version: 4.0.5 PHP Bug Type: MSSQL related Bug description: mssql.min_error_severity or mssql.min_message_severity have no effect mssql.min_message_severity mssql.min_error_severity in the php.ini file have no effect on messages received from MSSQL. I am running MSSQL 7.0 SP2. I still get Changed database context to 'dbname'. warning on queries even after setting the above values to greater than 10. The above warning is a level 10 warning. -- Edit Bug report at: http://bugs.php.net/?id=10901edit=1 -- 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 #10878 Updated: Compile problem with IMAP support
ID: 10878 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: IMAP related Operating system: sparc-sun-solaris2.7 PHP Version: 4.0.5 Description: Compile problem with IMAP support Sorry no I have tried it with --with-imap I am running the most recent version ftp://ftp.cac.washington.edu/imap/imap.tar.Z Previous Comments: --- [2001-05-16 00:17:48] [EMAIL PROTECTED] Is there really a path 'y' in your system? What version of c-client you have? And where is it located? and the header files? --Jani --- [2001-05-15 10:14:45] [EMAIL PROTECTED] configure line is: ./configure --with-mysql=/usr --with-imap=y --with-apache=../apache_1.3.19 --enable-track-vars --enable-register-globals --enable-trans-sid make[2]: Entering directory `/usr/local/src/php-4.0.5/main' gcc -I. -I/usr/local/src/php-4.0.5/main -I/usr/local/src/php-4.0.5/main -I/usr/local/src/php-4.0.5 -I/usr/local/src/apache_1.3.19/s rc/include -I/usr/local/src/apache_1.3.19/src/os/unix -I/usr/local/src/php-4.0.5/Zend -I/usr/include/mysql -I/usr/local/src/php-4.0. 5/ext/xml/expat/xmltok -I/usr/local/src/php-4.0.5/ext/xml/expat/xmlparse -I/usr/local/src/php-4.0.5/TSRM -D_POSIX_PTHREAD_SEMANTICS -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -O2 -c main.c touch main.lo gcc -I. -I/usr/local/src/php-4.0.5/main -I/usr/local/src/php-4.0.5/main -I/usr/local/src/php-4.0.5 -I/usr/local/src/apache_1.3.19/s rc/include -I/usr/local/src/apache_1.3.19/src/os/unix -I/usr/local/src/php-4.0.5/Zend -I/usr/include/mysql -I/usr/local/src/php-4.0. 5/ext/xml/expat/xmltok -I/usr/local/src/php-4.0.5/ext/xml/expat/xmlparse -I/usr/local/src/php-4.0.5/TSRM -D_POSIX_PTHREAD_SEMANTICS -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -O2 -c internal_functions.c touch internal_functions.lo In file included from internal_functions.c:32: /usr/local/src/php-4.0.5/ext/imap/php_imap.h:50: parse error before `MAILSTREAM' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:50: warning: no semicolon at end of struct or union /usr/local/src/php-4.0.5/ext/imap/php_imap.h:58: parse error before `}' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:58: warning: data definition has no type or storage class /usr/local/src/php-4.0.5/ext/imap/php_imap.h:61: parse error before `SIZEDTEXT' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:61: warning: no semicolon at end of struct or union /usr/local/src/php-4.0.5/ext/imap/php_imap.h:65: parse error before `}' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:65: warning: data definition has no type or storage class /usr/local/src/php-4.0.5/ext/imap/php_imap.h:68: parse error before `SIZEDTEXT' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:68: warning: no semicolon at end of struct or union /usr/local/src/php-4.0.5/ext/imap/php_imap.h:70: conflicting types for `next' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:64: previous declaration of `next' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:71: parse error before `}' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:71: warning: data definition has no type or storage class /usr/local/src/php-4.0.5/ext/imap/php_imap.h:156: parse error before `STRINGLIST' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:156: warning: no semicolon at end of struct or union /usr/local/src/php-4.0.5/ext/imap/php_imap.h:157: warning: data definition has no type or storage class /usr/local/src/php-4.0.5/ext/imap/php_imap.h:158: parse error before `*' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:158: warning: data definition has no type or storage class /usr/local/src/php-4.0.5/ext/imap/php_imap.h:159: parse error before `*'
Re: [PHP-DEV] Latest commit -- depreciation of call_user_method()
On Wed, 16 May 2001, Jani Taskinen wrote: Have you ever heard that you can also change that number in the middle? 4.0.6 This one^ It can be something else than an ellipse called zero..it can even be a number 1!!! Whoa! Never thougth about that?! And maybe, just MAYBE then these people (who you seem to think of as complete idiots) would READ the NEWS file? Or e.g. RELEASE_NOTES ? Or is that number in the middle reserved for something special? Something the 'group' only know of and don't want to tell us lower class people? Maybe the 'group' could take their thumbs out of their asses and start DOING something? And maybe they could start listening to new ideas for once and a while. Or is the 'group' nowadays only Zeev/Andi ? It would be really nice to hear from the other members of the 'group' also as it really seems like the only ones speaking for it are Zeev/Andi.. Or could someone please define the function of this mysterious 'group' ? (And please, someone else than Zeev/Andi.. :) Being antagonistically sarcastic won't win you any friends, Jani. As far as your question about the version numbers, the middle digit gets bumped up when we plan some changes that will break backwards compatibility and implement features in the core language. So, yes, it is something special, it's not for bug fixes or extension changes. -Andrei Politics is for the moment, an equation is for eternity. -- Albert Einstein -- 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] issues about domxml in 4.0.6
On Wed, 16 May 2001, Christian Stocker wrote: Hello As mentioned in bug #9896 the api for domxml seems to has changed a lot... it's now almost impossible to write code with domxml which works in 4.0.5 and 4.0.6. for example $root-children() returns a completely different Array (tagname instead of name and so on...). Does this make sense for a minor-update? And all the domxml function still just produce a segfault on 4.0.6. if this is not supported anymore, fine ($root-children() instead of domxml_children($root) works also in 4.0.5), but i'd prefer a fatal error instead of a segfault :) Maybe I have to live with all these api-changes and as soon as all our servers have 4.0.6, it won't be a problem for me. But I think i'm not the only one which disturbs that a little bit. I fixed a few memory leaks I found in that extension, but my feeling is that there are still lots of them and also many bugs lurking in there. I don't know where Uwe is or what he plans to do with the extension.. -Andrei * Syntactic sugar causes cancer of the semicolon. -- Alan Perlis * -- 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: AW: AW: [PHP-DEV] arrays
At 13:34 16/5/2001, Stig Sæther Bakken wrote: Acknowledged. But IMO the arrays will be either clearly continous or clearly associative/non-continous in 99.2% of the cases (Zeev statistics applied). I never claim to be accurate, I usually say 99% :) I think it's fine to keep treating an array as non-continous if there has ever been holes or string keys in it. I actually think that arrays with both numeric and associative indices are quite common. Lots of apps I've seen use them, as well as some of PHP's internal functions. Zeev -- 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] Latest commit -- depreciation of call_user_method()
At 14:06 16/5/2001, Jani Taskinen wrote: On Wed, 16 May 2001, Zeev Suraski wrote: Also bare in mind that a very large percentage of the developers don't *want* to be forced to change their code, and consider it to be a Who's forcing anybody to update anyway? We are, by not supporting old versions (i.e., no bug fixes, no security updates, no nothing). misfeature in the language if it breaks downwards compatibility in between releases, regardless of whether they get a clear notification about it or not. It seems like everybody just ignores my emails..oh well. So I can rant again. :-p I don't ignore your Email; I answered you. Have you ever heard that you can also change that number in the middle? 4.0.6 This one^ It can be something else than an ellipse called zero..it can even be a number 1!!! Whoa! Never thougth about that?! So what? ISPs and many companies won't be bothered even if you change the ellipse to the number of the beast. So what. It breaks compatibility. And maybe, just MAYBE then these people (who you seem to think of as complete idiots) would READ the NEWS file? Or e.g. RELEASE_NOTES ? It has nothing to do with their level of stupidity, or even ignorance. They can be Einsteins, but breaking downwards compatibility means we're giving them work to do, work that they don't want to do, and shouldn't be forced to do. Or is that number in the middle reserved for something special? Something the 'group' only know of and don't want to tell us lower class people? Maybe the 'group' could take their thumbs out of their asses and start DOING something? And maybe they could start listening to new ideas for once and a while. Or is the 'group' nowadays only Zeev/Andi ? It would be really nice to hear from the other members of the 'group' also as it really seems like the only ones speaking for it are Zeev/Andi.. Or could someone please define the function of this mysterious 'group' ? (And please, someone else than Zeev/Andi.. :) I'll let that topic slide for now. We'll get around to it soon. At any rate, other than your mood, the issue of the group has nothing to do with this issue. Zeev -- 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 #10902: Possible security hole via external modification of session vars
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.5 PHP Bug Type: *Session related Bug description: Possible security hole via external modification of session vars This is kind of similar to the old file upload problem, where you could set variables in a POST. In some cases (depends on the way the code is written), if a site stores login status (eg. user name, etc) in session variables after an authorisation check, it is possible to pass values as the same-named session vars, and therefore actually bypass the authorisation step getting access to restricted areas. -- Edit Bug report at: http://bugs.php.net/?id=10902edit=1 -- 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 #10902 Updated: Possible security hole via external modification of session vars
ID: 10902 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: *Session related Operating system: Linux PHP Version: 4.0.5 Description: Possible security hole via external modification of session vars Not really a bug, just an issue. Previous Comments: --- [2001-05-16 10:17:14] [EMAIL PROTECTED] This is kind of similar to the old file upload problem, where you could set variables in a POST. In some cases (depends on the way the code is written), if a site stores login status (eg. user name, etc) in session variables after an authorisation check, it is possible to pass values as the same-named session vars, and therefore actually bypass the authorisation step getting access to restricted areas. --- Full Bug description available at: http://bugs.php.net/?id=10902 -- 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 #10878 Updated: Compile problem with IMAP support
ID: 10878 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: IMAP related Operating system: sparc-sun-solaris2.7 PHP Version: 4.0.5 Description: Compile problem with IMAP support cp c-client.a /usr/lib/libc-client.a cp rfc822.h /usr/include cp linkage.h /usr/include cp mail.h /usr/include Previous Comments: --- [2001-05-16 09:31:27] [EMAIL PROTECTED] Sorry no I have tried it with --with-imap I am running the most recent version ftp://ftp.cac.washington.edu/imap/imap.tar.Z --- [2001-05-16 00:17:48] [EMAIL PROTECTED] Is there really a path 'y' in your system? What version of c-client you have? And where is it located? and the header files? --Jani --- [2001-05-15 10:14:45] [EMAIL PROTECTED] configure line is: ./configure --with-mysql=/usr --with-imap=y --with-apache=../apache_1.3.19 --enable-track-vars --enable-register-globals --enable-trans-sid make[2]: Entering directory `/usr/local/src/php-4.0.5/main' gcc -I. -I/usr/local/src/php-4.0.5/main -I/usr/local/src/php-4.0.5/main -I/usr/local/src/php-4.0.5 -I/usr/local/src/apache_1.3.19/s rc/include -I/usr/local/src/apache_1.3.19/src/os/unix -I/usr/local/src/php-4.0.5/Zend -I/usr/include/mysql -I/usr/local/src/php-4.0. 5/ext/xml/expat/xmltok -I/usr/local/src/php-4.0.5/ext/xml/expat/xmlparse -I/usr/local/src/php-4.0.5/TSRM -D_POSIX_PTHREAD_SEMANTICS -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -O2 -c main.c touch main.lo gcc -I. -I/usr/local/src/php-4.0.5/main -I/usr/local/src/php-4.0.5/main -I/usr/local/src/php-4.0.5 -I/usr/local/src/apache_1.3.19/s rc/include -I/usr/local/src/apache_1.3.19/src/os/unix -I/usr/local/src/php-4.0.5/Zend -I/usr/include/mysql -I/usr/local/src/php-4.0. 5/ext/xml/expat/xmltok -I/usr/local/src/php-4.0.5/ext/xml/expat/xmlparse -I/usr/local/src/php-4.0.5/TSRM -D_POSIX_PTHREAD_SEMANTICS -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -O2 -c internal_functions.c touch internal_functions.lo In file included from internal_functions.c:32: /usr/local/src/php-4.0.5/ext/imap/php_imap.h:50: parse error before `MAILSTREAM' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:50: warning: no semicolon at end of struct or union /usr/local/src/php-4.0.5/ext/imap/php_imap.h:58: parse error before `}' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:58: warning: data definition has no type or storage class /usr/local/src/php-4.0.5/ext/imap/php_imap.h:61: parse error before `SIZEDTEXT' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:61: warning: no semicolon at end of struct or union /usr/local/src/php-4.0.5/ext/imap/php_imap.h:65: parse error before `}' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:65: warning: data definition has no type or storage class /usr/local/src/php-4.0.5/ext/imap/php_imap.h:68: parse error before `SIZEDTEXT' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:68: warning: no semicolon at end of struct or union /usr/local/src/php-4.0.5/ext/imap/php_imap.h:70: conflicting types for `next' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:64: previous declaration of `next' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:71: parse error before `}' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:71: warning: data definition has no type or storage class /usr/local/src/php-4.0.5/ext/imap/php_imap.h:156: parse error before `STRINGLIST' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:156: warning: no semicolon at end of struct or union /usr/local/src/php-4.0.5/ext/imap/php_imap.h:157: warning: data definition has no type or storage class /usr/local/src/php-4.0.5/ext/imap/php_imap.h:158: parse error before `*' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:158:
[PHP-DEV] Bug #7821 Updated: Unresolved symbol with GD
ID: 7821
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: *Configuration Issues
Operating system: HP-UX 10.20
PHP Version: php4-200105160045
Description: Unresolved symbol with GD
Okay, with the build php4-200105160045, I've this config message error :
...
checking for the location of libjpeg... yes
checking for jpeg_read_header in -ljpeg... yes
checking for the location of libpng... yes
checking for png_info_init in -lpng... yes
./configure[6]: no: not found.
checking for the location of libXpm... yes
checking for XpmFreeXpmImage in -lXpm... no
configure: error: libXpm.(a|so) or libX11.(a|so) not found!
In config.log :
...
configure:18240: checking for the location of libXpm
configure:18288: checking for XpmFreeXpmImage in -lXpm
configure:18309: gcc -o conftest -O2 -DHPUX10 -DMOD_SSL=208101 -DUSE_HSREGEX -DEAPI
-DUSE_EXPAT -L/PKl01h01/soft/web/lib -L/PKl01h01/soft/web/lib -L/PKl01h01/so
ft/web/src/php/lib -L/PKl01h01/soft/web/src/php/lib conftest.c -lXpm
-L/PKl01h01/soft/web/lib -lX11
-lpng -lz -ljpeg -lcrypt -lm 15
/usr/ccs/bin/ld: Can't find library for -lX11
collect2: ld returned 1 exit status
configure: failed program was:
#line 18298 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char XpmFreeXpmImage();
int main() {
XpmFreeXpmImage()
; return 0; }
Any idea ?
Thx :)
JC
Previous Comments:
---
[2001-05-16 01:06:00] [EMAIL PROTECTED]
What does it say in config.log about this ?
In the end of it.
And could you please try with latest snapshot from
http://snaps.php.net/ as the configure script for
GD has gone through a face lift.
--Jani
---
[2001-05-15 15:02:31] [EMAIL PROTECTED]
Hellow,
Here's the feedback :
When I add --with-xpm-dir=..., the configure program failed :
...
checking for libjpeg (needed by gd-1.8+)... yes
checking for jpeg_read_header in -ljpeg... yes
checking for libXpm (needed by gd-1.8+)... yes
checking for XpmFreeXpmImage in -lXpm... no
no
checking whether to include GD support... yes (static)
checking for gdImageString16 in -lgd... no
checking for gdImagePaletteCopy in -lgd... no
checking for gdImageColorClosestHWB in -lgd... no
checking for compress in -lz... no
checking for png_info_init in -lpng... no
checking for gdImageColorResolve in -lgd... no
checking for gdImageCreateFromPng in -lgd... no
checking for gdImageCreateFromGif in -lgd... no
checking for gdImageWBMP in -lgd... no
checking for gdImageCreateFromJpeg in -lgd... no
checking for gdImageCreateFromXpm in -lgd... no
checking whether to include FreeType 1.x support... yes
checking for T1lib support... no
checking whether to include GNU gettext support... no
checking for gmp support... no
checking for Hyperwave support... no
checking for ICAP support... no
checking for iconv support... no
checking for Kerberos support in IMAP... no
checking for SSL support in IMAP... no
checking for IMAP support... no
checking for Informix support... no
checking for Ingres II support... no
checking for InterBase support... no
checking for ircg support... no
checking for Java support... no
checking whether to include LDAP support... no
checking for MCAL support... no
checking for mcrypt support... no
checking for mhash support... no
checking whether to include ming support... no
checking for mnoGoSearch support... no
checking for mSQL support... no
checking for Muscat support... no
checking for MySQL support... no
checking for Oracle-OCI8 support... no
checking for Adabas support... no
checking for SAP DB support... no
checking for Solid support... no
checking for IBM DB2 support... no
checking for Empress support... no
checking for Velocis support... no
checking for a custom ODBC support... no
checking for iODBC support... no
checking for Easysoft ODBC-ODBC Bridge support... no
checking for unixODBC support... no
checking for OpenLink ODBC support... no
checking for DBMaker support... no
checking for Oracle-ORACLE support... no
checking for Ovrimos SQL Server support... no
checking whether to include PCRE support... yes
checking for memmove... (cached) yes
checking whether to include PDFlib support... yes
checking for libz needed by pdflib 3.x... already zlib support
checking for jpeg_read_header in -ljpeg... (cached) yes
checking for png_create_info_struct in -lpng... no
no
checking for TIFFOpen in -ltiff... no
no
checking for PDF_show_boxed in -lpdf... no
configure: error: pdflib extension requires pdflib 3.x.
I'll become crazy :p
An idea ?
Thx :)
---
[2001-04-28
Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] PHP 4.0.6RC1 ready for testing
At 14:19 16.05.2001 +0200, Petr Cech wrote: On Wed, May 16, 2001 at 12:44:39PM +0200 , Hellekin O. Wolf wrote: *** I just downloaded it and got some warning about a missing MSVCR70.dll : it seems to me that previous discussions elsewhere stated quite new, like a .NET thing... Sounds like libtool-1.4 on Debian to me =8\ people not having .Net installed would experience some problems when trying to use extensions that are relying upon openssl like the curl or openssl extension. http://www.php4win.de/openssl-0.9.6a.zip includes updated libaries that fixes that issue (can be used for 4.0.5 as well) daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.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] Bug #8672 Updated: Crash when returning a variable from function as argument
ID: 8672 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Closed Bug Type: Variables related Operating system: Redhat Linux 6.2 PHP Version: 4.0.4 Description: Crash when returning a variable from function as argument I can't reproduce this with 4.0.5. Seems to be fixed ;) Previous Comments: --- [2001-05-16 01:02:47] [EMAIL PROTECTED] Does this happen with PHP 4.0.5 or not? --Jani --- [2001-04-28 14:45:15] [EMAIL PROTECTED] Can you try to reprocude this when php 4.0.5 will be released next week? --- [2001-01-12 05:30:39] [EMAIL PROTECTED] I had code like this: $user = new eZUser( $session-variable(AuthenticatedUser ) ); And I noticed now that this creates a segfault in php. The workaround is changing the code to: $val = $session-variable( AuthenticatedUser ); $user = new eZUser( $val ); The code worked with php-4.0.3pl1 and has worked with 4.0.4, but it's reproduceable and I think it's a PHP bug. The eZSession::variable() function returns a string value. I've tested it with 4.0.4pl1 and the bug is still there. --- Full Bug description available at: http://bugs.php.net/?id=8672 -- 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 #10902 Updated: Possible security hole via external modification of session vars
ID: 10902 Updated by: cynic Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Bogus Bug Type: *Session related Operating system: PHP Version: 4.0.5 Assigned To: Comments: this could only happen with a misconfigured PHP - you would have to set it to register globals AND extract GET/POST data AFTER session data. proper configuration is an admin reponsibility. Previous Comments: --- [2001-05-16 10:19:23] [EMAIL PROTECTED] Not really a bug, just an issue. --- [2001-05-16 10:17:14] [EMAIL PROTECTED] This is kind of similar to the old file upload problem, where you could set variables in a POST. In some cases (depends on the way the code is written), if a site stores login status (eg. user name, etc) in session variables after an authorisation check, it is possible to pass values as the same-named session vars, and therefore actually bypass the authorisation step getting access to restricted areas. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10902edit=2 -- 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] Latest commit -- depreciation of call_user_method()
Hi Andrei. Yes, that's how it should be, but not how it is. At least I've been observing PHP 4.0.x evolve dramatically with compat breakage included. At 08:34 16.5. 2001 -0500, Andrei Zmievski wrote: As far as your question about the version numbers, the middle digit gets bumped up when we plan some changes that will break backwards compatibility and implement features in the core language. So, yes, it is something special, it's not for bug fixes or extension changes. -Andrei [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- 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 #10898 Updated: is_dir filetype return wrong values
ID: 10898
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Filesystem function related
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
this is bogus. you have to either chdir() into the $parent or is_dir() the full path.
Previous Comments:
---
[2001-05-16 08:35:02] [EMAIL PROTECTED]
A little script that should echo alle filetypes of all files in any subdir of the
parent provided.
Now I use opendir to test wether the file is a dir, but this isn't a good solution, is
it?
The is_dir() allways returns false
the filetype() allwyas returns dir
?php
function getFileInfo($parent)
{
$handle = opendir($parent);
while ($file = readdir($handle))
{
$filelist[]=$file ;
}
reset($filelist);
while(list(,$f)=each ($filelist))
{
if ($f!=. $f!=..)
{
if(is_dir($f))
{
getFileInfo($f);
}
else
{
echo filetype($f);
}
}
}
}
getFileInfo(c:datapdf);
?
---
[2001-05-16 06:23:07] [EMAIL PROTECTED]
Please provide a short script so that we can reproduce it.
Derick
---
[2001-05-16 05:44:07] [EMAIL PROTECTED]
Hello,
I'm running php 4.0.5 on my win ME Win NT 4.0 and I have experienced 2 functions
returning the wrong values. I don't know if this bug is allready reported.
the is_dir() allways returns false except for . ..
the filetype() allways returns dir
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10898edit=2
--
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 #10878 Updated: Compile problem with IMAP support
ID: 10878 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: IMAP related Operating system: sparc-sun-solaris2.7 PHP Version: 4.0.5 Description: Compile problem with IMAP support --with-imap=../imap-2001 (Same thing) --with-imap=/usr/include (Same thing) Previous Comments: --- [2001-05-16 10:20:42] [EMAIL PROTECTED] cp c-client.a /usr/lib/libc-client.a cp rfc822.h /usr/include cp linkage.h /usr/include cp mail.h /usr/include --- [2001-05-16 09:31:27] [EMAIL PROTECTED] Sorry no I have tried it with --with-imap I am running the most recent version ftp://ftp.cac.washington.edu/imap/imap.tar.Z --- [2001-05-16 00:17:48] [EMAIL PROTECTED] Is there really a path 'y' in your system? What version of c-client you have? And where is it located? and the header files? --Jani --- [2001-05-15 10:14:45] [EMAIL PROTECTED] configure line is: ./configure --with-mysql=/usr --with-imap=y --with-apache=../apache_1.3.19 --enable-track-vars --enable-register-globals --enable-trans-sid make[2]: Entering directory `/usr/local/src/php-4.0.5/main' gcc -I. -I/usr/local/src/php-4.0.5/main -I/usr/local/src/php-4.0.5/main -I/usr/local/src/php-4.0.5 -I/usr/local/src/apache_1.3.19/s rc/include -I/usr/local/src/apache_1.3.19/src/os/unix -I/usr/local/src/php-4.0.5/Zend -I/usr/include/mysql -I/usr/local/src/php-4.0. 5/ext/xml/expat/xmltok -I/usr/local/src/php-4.0.5/ext/xml/expat/xmlparse -I/usr/local/src/php-4.0.5/TSRM -D_POSIX_PTHREAD_SEMANTICS -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -O2 -c main.c touch main.lo gcc -I. -I/usr/local/src/php-4.0.5/main -I/usr/local/src/php-4.0.5/main -I/usr/local/src/php-4.0.5 -I/usr/local/src/apache_1.3.19/s rc/include -I/usr/local/src/apache_1.3.19/src/os/unix -I/usr/local/src/php-4.0.5/Zend -I/usr/include/mysql -I/usr/local/src/php-4.0. 5/ext/xml/expat/xmltok -I/usr/local/src/php-4.0.5/ext/xml/expat/xmlparse -I/usr/local/src/php-4.0.5/TSRM -D_POSIX_PTHREAD_SEMANTICS -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -O2 -c internal_functions.c touch internal_functions.lo In file included from internal_functions.c:32: /usr/local/src/php-4.0.5/ext/imap/php_imap.h:50: parse error before `MAILSTREAM' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:50: warning: no semicolon at end of struct or union /usr/local/src/php-4.0.5/ext/imap/php_imap.h:58: parse error before `}' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:58: warning: data definition has no type or storage class /usr/local/src/php-4.0.5/ext/imap/php_imap.h:61: parse error before `SIZEDTEXT' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:61: warning: no semicolon at end of struct or union /usr/local/src/php-4.0.5/ext/imap/php_imap.h:65: parse error before `}' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:65: warning: data definition has no type or storage class /usr/local/src/php-4.0.5/ext/imap/php_imap.h:68: parse error before `SIZEDTEXT' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:68: warning: no semicolon at end of struct or union /usr/local/src/php-4.0.5/ext/imap/php_imap.h:70: conflicting types for `next' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:64: previous declaration of `next' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:71: parse error before `}' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:71: warning: data definition has no type or storage class /usr/local/src/php-4.0.5/ext/imap/php_imap.h:156: parse error before `STRINGLIST' /usr/local/src/php-4.0.5/ext/imap/php_imap.h:156: warning: no semicolon at end of struct or union /usr/local/src/php-4.0.5/ext/imap/php_imap.h:157: warning: data definition has no type or storage class
Re: [PHP-DEV] removing ereg functions
No, sorry, I think you misunderstood my question. I would just like to see a --disable-ereg option for configure. I would never dream of removing ereg from PHP as a supported function set. It would break Phorum and lots of stuff I have written. I understand your reaction now Rasmus. Sorry for the confusion. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, May 16, 2001 3:17 AM Subject: Re: [PHP-DEV] removing ereg functions At 08:50 16/5/2001, Brian Moon wrote: Is it possible to remove the ereg functions? We have a strict policy to only use preg as they are more reliable and faster. So, I am not to happy that PHP is bloated with these ereg functions. Any thoughts? Wow, it's like a plague out there. :) No way. ereg() has got to be used by millions of code lines around the world. I don't see it being removed in this millennium. These functions can fit nicely into the lean-and-mean approach. Zeev -- 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 #10904: php.exe accesses unreadable memory and crashes
From: [EMAIL PROTECTED] Operating system: WINNT SP4 PHP version: 4.0.5 PHP Bug Type: Reproducible crash Bug description: php.exe accesses unreadable memory and crashes WINNT SP4, APACHE 1.3.14, PHP 4.0.4 and 4.0.5 I cannot make a gdb backtrace, but I can give you the following: 1) It is an access violation -- the instruction at 0x0dsd5973 referenced 0x. the memory could not be read. 2) It always occurs near the end of a script and is not related to what HTML happens to be generated. Most scripts do not show the error at all, but when one does only changing the size of the output (either very small or very large) will suppress it. 3) After clearing the error (by clicking OK on the error message on the server), the full HTML is always produced correctly. However, until OK is clicked, the client is left waiting for the last 1K or so of output). 4) It is defintely related to the size of the output. Scripts that make output smaller then 1K never show the error. Larger scripts may or may not show the error, but when they do, the error can always be removed by making the script generate a very large output (~100K). I just repeated the same content x times. Once x is large enough, the bug goes away. 5) On my system, calling phpinfo causes it -- ?php phpinfo() ? -- but only on the second and subsequent calls after rebooting the server. Just starting and stopping Apache does not allow the first good call to succeed--the server must be rebooted. 6) changing imlicit_flush, output_buffering, and memory_limit in php.ini do not fix it, but might(???) alter the size of output that exhibts the problem. flush() in the code does not fix it. 7) I theorize it is related to some final cleanup or garbage collection code. 8) I first saw it in 4.0.4 and upgraded to 4.0.5 hoping to see it go away. It did not, but again the size of output that shows the error might(???) have changed. One point about the upgrade, I could not copy msvcrt.dll to the system root because it was always locked by the OS, even after closing all closable services. My msvcrt.dll is dated three days earlier than the one distributed with PHP 4.0.4 and 4.0.5. There appears to be no way to change it. --This bug could easily exist under another OS, but be invisible (and harmless) if the OS does not generate an error message for the address violation. Hope this is helpful. Feel free to contact me. Steve -- Edit Bug report at: http://bugs.php.net/?id=10904edit=1 -- 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 ereg functions
Aha, ok :) That makes much more sense indeed. At 17:52 16/5/2001, Brian Moon wrote: No, sorry, I think you misunderstood my question. I would just like to see a --disable-ereg option for configure. I would never dream of removing ereg from PHP as a supported function set. It would break Phorum and lots of stuff I have written. I understand your reaction now Rasmus. Sorry for the confusion. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, May 16, 2001 3:17 AM Subject: Re: [PHP-DEV] removing ereg functions At 08:50 16/5/2001, Brian Moon wrote: Is it possible to remove the ereg functions? We have a strict policy to only use preg as they are more reliable and faster. So, I am not to happy that PHP is bloated with these ereg functions. Any thoughts? Wow, it's like a plague out there. :) No way. ereg() has got to be used by millions of code lines around the world. I don't see it being removed in this millennium. These functions can fit nicely into the lean-and-mean approach. Zeev -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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 #10904 Updated: php.exe accesses unreadable memory and crashes
ID: 10904
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating system: WINNT SP4
PHP Version: 4.0.5
Description: php.exe accesses unreadable memory and crashes
This script reproduces the bug on my machine:
?php
print html;
print head;
printtitlebug/title;
print /head;
print body;
for ($i=0; $i1000; $i++) {
print BRhello ;
}
print /body;
print /html;
?
Change 1000 to 333 and the bug disappears,
Change 1000 to 2 and the bug disappears.
Previous Comments:
---
[2001-05-16 11:02:35] [EMAIL PROTECTED]
WINNT SP4, APACHE 1.3.14, PHP 4.0.4 and 4.0.5
I cannot make a gdb backtrace, but I can give you the following:
1) It is an access violation -- the instruction at 0x0dsd5973 referenced 0x.
the memory could not be read.
2) It always occurs near the end of a script and is not related to what HTML happens
to be generated. Most scripts do not show the error at all, but when one does only
changing the size of the output (either very small or very large) will suppress it.
3) After clearing the error (by clicking OK on the error message on the server), the
full HTML is always produced correctly. However, until OK is clicked, the client is
left waiting for the last 1K or so of output).
4) It is defintely related to the size of the output. Scripts that make output
smaller then 1K never show the error. Larger scripts may or may not show the error,
but when they do, the error can always be removed by making the script generate a very
large output (~100K). I just repeated the same content x times. Once x is large
enough, the bug goes away.
5) On my system, calling phpinfo causes it -- ?php phpinfo() ? -- but only on the
second and subsequent calls after rebooting the server. Just starting and stopping
Apache does not allow the first good call to succeed--the server must be rebooted.
6) changing imlicit_flush, output_buffering, and memory_limit in php.ini do not fix
it, but might(???) alter the size of output that exhibts the problem. flush() in the
code does not fix it.
7) I theorize it is related to some final cleanup or garbage collection code.
8) I first saw it in 4.0.4 and upgraded to 4.0.5 hoping to see it go away. It did
not, but again the size of output that shows the error might(???) have changed. One
point about the upgrade, I could not copy msvcrt.dll to the system root because it was
always locked by the OS, even after closing all closable services. My msvcrt.dll is
dated three days earlier than the one distributed with PHP 4.0.4 and 4.0.5. There
appears to be no way to change it.
--This bug could easily exist under another OS, but be invisible (and harmless) if the
OS does not generate an error message for the address violation.
Hope this is helpful. Feel free to contact me.
Steve
---
Full Bug description available at: http://bugs.php.net/?id=10904
--
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 ereg functions
In my mind the problem that Brian raised is that ereg is slow. The solution is not to ban eregi but to fix it by performance tuning the C code. Just my 2c worth. John Lim Rasmus Lerdorf [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... That is why I am asking. Is there a core reason that the ereg functions have to be there? I could extend this to other functions as well of course. But this set in particular I have wondered about. 1) There was no PCRE library when I first added regex support to PHP. Henry Spencer's regex library, although not my initial choice, was chosen because that is what came bundled with Apache. 2) The ereg_* functions implement the Posix 1003.2 extended regular expression standard. The same regular expressions found in the Unix command line utils like grep, egrep and fgrep. The preg_* functions support the perverted Perl-style regular expressions. 3) Removing the ereg_* functions would cause a backward compatibility nightmare. Thousands, if not hundreds of thousands of scripts out there would have to be converted. 4) If you are using Apache you already have the library linked in anyway. Removing PHP support wouldn't save you any bloat. Not that this bloat is at all significant on any modern OS with shared pages. -Rasmus -- 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 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] LDAP V3 Server Side Sorting
If we are to follow the Netscape API then we should have a ldap_search_ext() function which we can pass the results of the ldap_create_sort_control(), other server side and client side controls. We can then incorporate Virtual List View Control and Entry Change Notification Control along with the rest of LDAP Version 3 functionality. David On Wed, 16 May 2001, Stig Venaas wrote: On Tue, May 15, 2001 at 06:17:11PM -0700, David Giffin wrote: Hello, I added in a function to provide server side sorting on searches. This is a LDAP version 3 specific function, and uses the Netscape API so I have ifdef'ed the new function. It adds a sortstr attriubte to the ldap_search() function that already exists in php. There might be a better way to incorporate the code into php, but here is my first attempt. proto int ldap_sort_search(int link, string base_dn, string filter [, array attrs [, string sortstr [, int attrsonly [, int sizelimit [, int timelimit [, int deref]) First of all, in order to be backwards compatible, the argument must be added to the end. I'm a bit worried that the search function is getting rather complicated. Sorting could be done using ldap_set_option() which we already got, the problem is that the argument has a complicated structure. It's BER encoded sequence of sequence. ldap_set_option() could perhaps be made to take array a value and do BER encoding etc. but that's complicated. The solution I prefer I think, is to mirror the Netscape API and do something like ldap_create_sort_control(ldap, sortkeylist, 1, sortctrl); How about proto int ldap_server_sort(int link, array attrs, int reverse) All subsequent searches should then use this. We could turn it off if it's called with empty attrs array. When it is on, searches should then include this control, like you did. Maybe my solution sounds ugly, it is more complicated to implement. I'm just starting to get concerned with all the arguments to ldap_search() and I think to have it close to the C API if possible. And if you are to have backwards compatibility, adding it as final argument to ldap_search() means that users always must supply all the other optional arguments. Stig -- 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 ereg functions
The problem is not the PHP C code. It is the regex library. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: John Lim [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 16, 2001 10:51 AM Subject: Re: [PHP-DEV] removing ereg functions In my mind the problem that Brian raised is that ereg is slow. The solution is not to ban eregi but to fix it by performance tuning the C code. Just my 2c worth. John Lim Rasmus Lerdorf [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... That is why I am asking. Is there a core reason that the ereg functions have to be there? I could extend this to other functions as well of course. But this set in particular I have wondered about. 1) There was no PCRE library when I first added regex support to PHP. Henry Spencer's regex library, although not my initial choice, was chosen because that is what came bundled with Apache. 2) The ereg_* functions implement the Posix 1003.2 extended regular expression standard. The same regular expressions found in the Unix command line utils like grep, egrep and fgrep. The preg_* functions support the perverted Perl-style regular expressions. 3) Removing the ereg_* functions would cause a backward compatibility nightmare. Thousands, if not hundreds of thousands of scripts out there would have to be converted. 4) If you are using Apache you already have the library linked in anyway. Removing PHP support wouldn't save you any bloat. Not that this bloat is at all significant on any modern OS with shared pages. -Rasmus -- 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 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 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 #10905: ImageGif (ImagePNG) output uncompressed
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.5 PHP Bug Type: Output Control Bug description: ImageGif (ImagePNG) output uncompressed Using the compression ob_gzhandler all HTML Pages get compressed well. But dynamic generated Images don't get compressed. Header of the output says, it is compressed, but the data following the header isn't. So those images can't be displayed (by at least netscape) Thanks for the patch, ;-) mike PS: Don't tell me that it isn't useful to gzip images, but if you have switched compression to 'enabled' in your php.ini file and you are creating images on the fly, you'll need it to handle this case correctly. -- Edit Bug report at: http://bugs.php.net/?id=10905edit=1 -- 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 ereg functions
I guess it just seems a little odd too me that PCRE is optional and POSIX is not. I know the history and all. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Rasmus Lerdorf [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, May 16, 2001 11:33 AM Subject: Re: [PHP-DEV] removing ereg functions No, sorry, I think you misunderstood my question. I would just like to see a --disable-ereg option for configure. I would never dream of removing ereg from PHP as a supported function set. It would break Phorum and lots of stuff I have written. I just don't see the point in this. There are other functions like split() that rely on the ereg code, and since removing the code isn't actually going to save you anything as the library is non-optional in Apache, removing the hooks from PHP makes no sense. I don't think disabling functions in PHP is a good way to enforce coding conventions. -Rasmus -- 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 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 ereg functions
Next thing you know is that we have --disable-(your favorite function here) for half the functions in php. That's a bad precedent, IMHO. Vlad Brian Moon wrote: No, sorry, I think you misunderstood my question. I would just like to see a --disable-ereg option for configure. I would never dream of removing ereg from PHP as a supported function set. It would break Phorum and lots of stuff I have written. I understand your reaction now Rasmus. Sorry for the confusion. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, May 16, 2001 3:17 AM Subject: Re: [PHP-DEV] removing ereg functions At 08:50 16/5/2001, Brian Moon wrote: Is it possible to remove the ereg functions? We have a strict policy to only use preg as they are more reliable and faster. So, I am not to happy that PHP is bloated with these ereg functions. Any thoughts? Wow, it's like a plague out there. :) No way. ereg() has got to be used by millions of code lines around the world. I don't see it being removed in this millennium. These functions can fit nicely into the lean-and-mean approach. Zeev -- 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 ereg functions
wouldn't it be in at least the best interest to have split and other functions to use preg instead of ereg? this might add some bloat to code, but it might be an interesting default speedup. by all means, keep ereg. unless you can get ereg to act just like preg, you can't get rid of it. On Wed, May 16, 2001 at 09:33:48AM -0700, Rasmus Lerdorf wrote: No, sorry, I think you misunderstood my question. I would just like to see a --disable-ereg option for configure. I would never dream of removing ereg from PHP as a supported function set. It would break Phorum and lots of stuff I have written. I just don't see the point in this. There are other functions like split() that rely on the ereg code, and since removing the code isn't actually going to save you anything as the library is non-optional in Apache, removing the hooks from PHP makes no sense. I don't think disabling functions in PHP is a good way to enforce coding conventions. -Rasmus -- 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 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] Latest commit -- depreciation of call_user_method()
new way: call_user_func(array($obj, method), method, args, go, here); ---^ isn't 'pass by reference' deprecated too ? harald. -- 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] Latest commit -- depreciation of call_user_method()
Harald Radi wrote: new way: call_user_func(array($obj, method), method, args, go, here); ---^ isn't 'pass by reference' deprecated too ? yes, so? the above is not pass by reference, your passing an array to the function, not a reference to an array. -sterling -- 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: Integer casts broken or...?
In some really rare cases, but who is purposely using
(int) 0x... anyway, and trusting on 0x being NOT
recognised??? And in user-submitted data, this just
adds another feature to most apps :), without any
programming.
The feature that non-numeric characters after the number
are ignored is only the best-of-worse-things to do
if you don't want to possible return errors on
casting to int.
Greetz,
Jeroen
On Wed, 16 May 2001, Brian Moon wrote:
Making (int) recognize Hex values is a bad idea to me. It could
potentially
break current code.
Brian Moon
--
dealnews.com, Inc.
Makers of dealnews dealmac
http://dealnews.com/ | http://dealmac.com/
- Original Message -
From: Jeroen [EMAIL PROTECTED]
To: Jeroen [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, May 16, 2001 1:04 PM
Subject: Re: [PHP-DEV] Integer casts broken or...?
Brian Moon writes:
I know it would confuse me to have 0009 turned into an octal or hex
if
I
type cast it to (int). When I think of (int), I only think of their
ultimate decimal value. Perhaps there needs to be a new type cast
((hex)?
(oct)?) that will interpret variables in their hex or octal value.
I
know
it is still a long integer in value, but it is a different
representation of
that number.
That's along the lines of what I was thinking--another cast (and
perhaps an optional arg to intval()?) which would respect the
base--maybe not separate (oct) or (hex)--or maybe so--or something
like (intbase) which just respected the base (since octal and hex are
the only ones strtol() claims to handle anyway). I admit that name is
clumsy at best. :) As it stands is_numeric('0x24') returns true but
intval('0x24') returns 0--which seems to conflict. Changing the
existing cast would probably surprise a lot of people though :).
A new cast is IMO no good idea. A cast is a way to enforce
converting to another TYPE, and that is not the case here.
The default string - int behaviour (is doesn't matter whether
implicit or explicit (resp. type-juggling and casting)) could
be improved to understand hex, but is definitely should NOT,
I repeat NOT understand octal numbers. Octal numbers
are obsolete (I've only seen them in chmod-like functions,
nowhere else.), and it would confuse a lot of people.
Mostly this function is called over user-supplied data,
and 90% of that users are still confused about why
the heck the internet uses forward-slashes, let alone
they know what octal means.
But it should be made possible of course, if you're certain
what you're doing.
Summary:
- enhance string - int conversion to understand hex.
- get an optional argument to intval as a possibility
to make it understand octals.
What WOULD be nice cast (i realise i'm now contradicting
myself) is (number)
(number) $a
should be completely equivalent with
0 + $a
that is, $a wil be converted to int if possible, but if it
is too large, or contains a fraction symbol (the dot)
or an exponent, it should be converted to float
instead.
Greetz,
Jeroen
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://www.A-Eskwadraat.nl/~jeroen
--
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 ereg functions
yes, PCRE is part of Apache-2.0 On Wed, 16 May 2001 -0400, [EMAIL PROTECTED] wrote: Rasmus Lerdorf wrote: But, that all makes sense and tells me that it is not worth pursuing. Is the regex lib bundled with apache always as part of the core or just included with certain modules? It is part of the core. As Apache 2.0, I believe PCRE is also a part of the Apache core? -Sterling -- 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] Latest commit -- depreciation of call_user_method()
At 01:06 PM 5/16/2001 +0200, Jani Taskinen wrote: On Wed, 16 May 2001, Zeev Suraski wrote: Also bare in mind that a very large percentage of the developers don't *want* to be forced to change their code, and consider it to be a Who's forcing anybody to update anyway? misfeature in the language if it breaks downwards compatibility in between releases, regardless of whether they get a clear notification about it or not. It seems like everybody just ignores my emails..oh well. So I can rant again. :-p Have you ever heard that you can also change that number in the middle? 4.0.6 This one^ It can be something else than an ellipse called zero..it can even be a number 1!!! Whoa! Never thougth about that?! And maybe, just MAYBE then these people (who you seem to think of as complete idiots) would READ the NEWS file? Or e.g. RELEASE_NOTES ? Or is that number in the middle reserved for something special? Something the 'group' only know of and don't want to tell us lower class people? Maybe the 'group' could take their thumbs out of their asses and start DOING something? And maybe they could start listening to new ideas for once and a while. Or is the 'group' nowadays only Zeev/Andi ? It would be really nice to hear from the other members of the 'group' also as it really seems like the only ones speaking for it are Zeev/Andi.. Or could someone please define the function of this mysterious 'group' ? (And please, someone else than Zeev/Andi.. :) I hope you don't mind me replying :) I agree with you that we can bump the second version number. I think the biggest question is if we were to create a 4.1.x in order to make changes (not features necessarily) which we think are important for standardization of function names, install paths and so on then how do we do it. There has been lots of talk and I think there have also been some good ideas. The only problem I have had with these discussions up to now is that people here really forget that the average PHP coder is not a php-dev guy who wants everything to be perfect. So we can maybe start making a plan for 4.1.x which would address this standardization but I would definitely urge to think of the average PHP user and give him an option which 95% of the time won't trash his site :) Andi -- 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 ereg functions
No, sorry, I think you misunderstood my question. I would just like to see a --disable-ereg option for configure. Wouldn't the disable_functions ini directive be of use here? -- Richard Heyes -- 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] sockets extension
hi, i've updated the sockets extension so that it's usable under win32 as well, however it's incompatible to the old extension for some reasons (thats why i want some feedback): sockets fd under win32 are usigned, the previous approach of returning long's and check for 0 wouldn't have worked, thus it's been converted to use resources (which is also cleaner behaviour IMO). the return values of most functions had to be changed, because win32 has an complete different error handling. as that together would already break old scripts i've also renamed the functions to (hopefully) go with the standards. daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de sockets.tar.gz -- 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] sockets extension
Daniel, Would it make sense to try to integrate the new php_streams into this extension? It might give php_streams a push and I'm sure Wez would work with you fixing any remaining issues. It would be a nice test bed. What do you think? About backwards compatibility, without having read the code it sounds as if you're doing the right thing as opposed to the old module. Do any of the new function names overlap with the old ones? I'm not quite sure how we should tackle backwards compatibility here. Andi At 09:28 PM 5/16/2001 +0200, Daniel Beulshausen wrote: hi, i've updated the sockets extension so that it's usable under win32 as well, however it's incompatible to the old extension for some reasons (thats why i want some feedback): sockets fd under win32 are usigned, the previous approach of returning long's and check for 0 wouldn't have worked, thus it's been converted to use resources (which is also cleaner behaviour IMO). the return values of most functions had to be changed, because win32 has an complete different error handling. as that together would already break old scripts i've also renamed the functions to (hopefully) go with the standards. daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.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 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] sockets extension
At 22:49 16.05.2001 +0300, Andi Gutmans wrote: Daniel, Would it make sense to try to integrate the new php_streams into this extension? It might give php_streams a push and I'm sure Wez would work with you fixing any remaining issues. It would be a nice test bed. What do you think? that surely would be a great idea, just didn't had the time to look at them yet. i'll do that tomorrow :) About backwards compatibility, without having read the code it sounds as if you're doing the right thing as opposed to the old module. Do any of the new function names overlap with the old ones? I'm not quite sure how we should tackle backwards compatibility here. i think the same, but i'm pretty sure that it'll break alot sockets scripts. daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.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] register_globals doesn't seem to be working
I was wondering if any of the developers out there might have a handle on this... I've recently recompiled my apache 1.3.19 binary to include static php4.05 support (in addition to mod_perl 1.25) on my Solaris 2.7 server so that I can run Squirrel Mail. Unfortunately the system does not seem to be registering the EGCPS as global variables, which Squirrel mail seems to depend on. I've checked and the variables DO exist in HTTP_*_VARS (ie: HTTP_POST_VARS[login_username] is populated properly but $login_username is blank/null.) I'm using the standard php.ini-dist file for my php.ini (which includes register_globals as On by default). I've tried switching it off, with no effect, and including the php_flag register_globals on directive in my httpd.conf, also with no effect. FYI, PHP was configured with the --with-gettext, --with-ldap, and --with-apache directives. I've search through the SquirrelMail and PHP archives and cannot find any other mention of someone having this problem. Given that I have zero experience with both SquirrelMail and PHP, I can easily see how this could be a bug located half-way between my keyboard and the back of my chair. However I like to think I'm not a complete idiot and have followed the simple install directions properly. Would anyone care to prove me wrong...please? Shawn South -- 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] sockets extension
At 04:01 16.05.2001 -0400, Sterling Hughes wrote: I've been meaning for a while to do this, so yes, that's perfectly ok. I don't quite understand the return values of most functions had to be changed because win32 has a completely different error handling. Can you elaborate a bit more. WSAGetlastError() returns completly different errno's, thus i think it's not a good idea to use them as return values (and for the users to rely on them). Also, strerror() is to my knowledge, available on Win32 systems (check out FormatMessage()). *ouch* I WILL NOT DO WINDOWS PROGRAMMING I WILL NOT DO WINDOWS PROGRAMMING ... as that together would already break old scripts i've also renamed the functions to (hopefully) go with the standards. The naming looks pretty good. It seems like most people want this (I don't, but, ah well.) great. daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.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] sockets extension
Daniel Beulshausen wrote: hi, i've updated the sockets extension so that it's usable under win32 as well, however it's incompatible to the old extension for some reasons (thats why i want some feedback): sockets fd under win32 are usigned, the previous approach of returning long's and check for 0 wouldn't have worked, thus it's been converted to use resources (which is also cleaner behaviour IMO). the return values of most functions had to be changed, because win32 has an complete different error handling. I've been meaning for a while to do this, so yes, that's perfectly ok. I don't quite understand the return values of most functions had to be changed because win32 has a completely different error handling. Can you elaborate a bit more. Also, strerror() is to my knowledge, available on Win32 systems (check out FormatMessage()). *ouch* I WILL NOT DO WINDOWS PROGRAMMING I WILL NOT DO WINDOWS PROGRAMMING ... as that together would already break old scripts i've also renamed the functions to (hopefully) go with the standards. The naming looks pretty good. It seems like most people want this (I don't, but, ah well.) Nice Job! -Sterling -- 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] issues about domxml in 4.0.6
I've contacted Uwe, and if he doesn't object (or respond ;) within the next day or so, I'll revert the commit in the 4_0_6 branch (leaving head alone). Whoa. Are you saying that 4.0.6 will revert to the domxml syntax that was in 4.0.4 and previous? And that 4.0.5 will just have it's own syntax? I've already updated all my scripts to the new syntax, assuming it was the way of the future. Don't tell me we are back-pedalling now! - Colin -- 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] sockets extension
At 22:49 16.05.2001 +0300, Andi Gutmans wrote: Daniel, Would it make sense to try to integrate the new php_streams into this extension? It might give php_streams a push and I'm sure Wez would work with you fixing any remaining issues. It would be a nice test bed. What do you think? About backwards compatibility, without having read the code it sounds as if you're doing the right thing as opposed to the old module. Do any of the new function names overlap with the old ones? I'm not quite sure how we should tackle backwards compatibility here. forgot to answer that, no the new function names don't overlap, thereprefixed i.e. socket - socket_create fd_dealloc - socket_fd_free create_listen_sock - socket_create_listen ... daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.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] issues about domxml in 4.0.6
Colin Viebrock wrote: I've contacted Uwe, and if he doesn't object (or respond ;) within the next day or so, I'll revert the commit in the 4_0_6 branch (leaving head alone). Whoa. Are you saying that 4.0.6 will revert to the domxml syntax that was in 4.0.4 and previous? And that 4.0.5 will just have it's own syntax? I've already updated all my scripts to the new syntax, assuming it was the way of the future. Don't tell me we are back-pedalling now! Ok, maybe I won't ;))) its odd though, the NEWS file seems to show that 4.0.6 is the release where the syntax changes, not 4.0.5, perhaps we're talking about two different commits (in 4.0.4 DOM-XML was also overhauled)? Its just the new syntax seems to be quite buggy (leaks and crashes) and a large amount of people are getting surprised and annoyed by the new syntax as the documentation does not reflect it, and neither do any of the notes in the NEWS file. -Sterling -- 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 #10908: Undeclared variables/URL declared variables
From: [EMAIL PROTECTED]
Operating system: WinME
PHP version: 4.0.5
PHP Bug Type: Scripting Engine problem
Bug description: Undeclared variables/URL declared variables
Ok, I ran this script on my Apache server with the new PHP 4.0.5 installed and it did
not work...
?
if($id=view){
echo You are in view mode;
}
else{
echo You are not in view mode;
?
br
form action=?id=view method=post
input type=submit value=Change to View Mode
/form
?
}
?
When you first view the page, it says You are not in view mode and has a submit
button that says Change to View Mode. If you click to button it will give $id the
value of view, so when it reloads the page, it will display You are in view mode.
This script works fine on my server with the earlier version of PHP, but not with
4.0.5. The new version 4.0.5 returns an error the first time it loads an says that $id
hasnt been defined.
I dont know if they changed it on the new version because they thought it was a bug of
the old versions(that didnt return errors for undeclared variables), but if thats the
case, they certainly disabled simple scripts like this one that made things a hell of
a lot easier for us programmers. Thats why I'm using the old version of PHP, and not
PHP 4.0.5 on my Apache server.
--
Edit Bug report at: http://bugs.php.net/?id=10908edit=1
--
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 #10909: Oops! Fix above bug I wrote
From: [EMAIL PROTECTED] Operating system: WinME PHP version: 4.0.5 PHP Bug Type: Scripting Engine problem Bug description: Oops! Fix above bug I wrote Oops! in the code in the above bug report, i made a mistake: Change if($id=view) to if($id==view) Thats how the original code I ran looked like. Sorry for the error, I was typing fast. -- Edit Bug report at: http://bugs.php.net/?id=10909edit=1 -- 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 #10908 Updated: Undeclared variables/URL declared variables
ID: 10908
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Scripting Engine problem
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
This is not a bug.
1. Use:
if ($id == view)
= : assignment
== : comparison
2. You can change your errorlevel, which is causing these
messages, see www.php.net/error_reporting
Previous Comments:
---
[2001-05-16 16:56:04] [EMAIL PROTECTED]
Ok, I ran this script on my Apache server with the new PHP 4.0.5 installed and it did
not work...
?
if($id=view){
echo You are in view mode;
}
else{
echo You are not in view mode;
?
br
form action=?id=view method=post
input type=submit value=Change to View Mode
/form
?
}
?
When you first view the page, it says You are not in view mode and has a submit
button that says Change to View Mode. If you click to button it will give $id the
value of view, so when it reloads the page, it will display You are in view mode.
This script works fine on my server with the earlier version of PHP, but not with
4.0.5. The new version 4.0.5 returns an error the first time it loads an says that $id
hasnt been defined.
I dont know if they changed it on the new version because they thought it was a bug of
the old versions(that didnt return errors for undeclared variables), but if thats the
case, they certainly disabled simple scripts like this one that made things a hell of
a lot easier for us programmers. Thats why I'm using the old version of PHP, and not
PHP 4.0.5 on my Apache server.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10908edit=2
--
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 #10910: var $foo = madness
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.0 Latest CVS (2001-05-16)
PHP Bug Type: Feature/Change Request
Bug description: var $foo = madness
class foo {
var $bar = Some string;
var $baz = new some_other_class_i_defined;
}
I would like for that to work, please. ;)
--
Edit Bug report at: http://bugs.php.net/?id=10910edit=1
--
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 #10909 Updated: Oops! Fix above bug I wrote
ID: 10909 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Bogus Bug Type: Scripting Engine problem Operating system: PHP Version: 4.0.5 Assigned To: Comments: Please do not open a bug report for the same 'bug' in the future. Just add your comments to the first one. regards, Derick Previous Comments: --- [2001-05-16 17:06:24] [EMAIL PROTECTED] Oops! in the code in the above bug report, i made a mistake: Change if($id=view) to if($id==view) Thats how the original code I ran looked like. Sorry for the error, I was typing fast. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10909edit=2 -- 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 #10910 Updated: var $foo = madness
ID: 10910
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Feature/Change Request
Operating system:
PHP Version: 4.0 Latest CVS (2001-05-16)
Assigned To:
Comments:
no way, initializer values have to be constants
use a constructor to initialize instead
Previous Comments:
---
[2001-05-16 17:07:16] [EMAIL PROTECTED]
class foo {
var $bar = Some string;
var $baz = new some_other_class_i_defined;
}
I would like for that to work, please. ;)
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10910edit=2
--
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] Adding charset - patch for php_imap.c
Attached is a suggested patch to make it possible to set the CHARSET parameter with imap_mail_compose(). Currently, all body parts with Content-Type = TYPETEXT get CHARSET=US-ASCII. Usage: $body[1][type] = TYPETEXT; $body[1][charset] = iso-8859-1; Chuck, if there are no objections to the patch, can you commit it? Best regards, /Johan Ekenberg -- 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 #10908 Updated: Undeclared variables/URL declared variables
ID: 10908
Updated by: lyric
Reported By: [EMAIL PROTECTED]
Old-Status: Bogus
Status: Open
Bug Type: Scripting Engine problem
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
Submitter added:
Oops! in the code in the above bug report, i made a mistake: Change
if($id=view) to if($id==view) Thats how the original code I ran looked like.
Sorry for the error, I was typing fast.
Your problem is simply that the error_level (as described by derick) is set higher
than you are used to. Still, the code should probably read something like
if (isset($id) ($id==view))
Previous Comments:
---
[2001-05-16 17:07:02] [EMAIL PROTECTED]
This is not a bug.
1. Use:
if ($id == view)
= : assignment
== : comparison
2. You can change your errorlevel, which is causing these
messages, see www.php.net/error_reporting
---
[2001-05-16 16:56:04] [EMAIL PROTECTED]
Ok, I ran this script on my Apache server with the new PHP 4.0.5 installed and it did
not work...
?
if($id=view){
echo You are in view mode;
}
else{
echo You are not in view mode;
?
br
form action=?id=view method=post
input type=submit value=Change to View Mode
/form
?
}
?
When you first view the page, it says You are not in view mode and has a submit
button that says Change to View Mode. If you click to button it will give $id the
value of view, so when it reloads the page, it will display You are in view mode.
This script works fine on my server with the earlier version of PHP, but not with
4.0.5. The new version 4.0.5 returns an error the first time it loads an says that $id
hasnt been defined.
I dont know if they changed it on the new version because they thought it was a bug of
the old versions(that didnt return errors for undeclared variables), but if thats the
case, they certainly disabled simple scripts like this one that made things a hell of
a lot easier for us programmers. Thats why I'm using the old version of PHP, and not
PHP 4.0.5 on my Apache server.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10908edit=2
--
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] Correction: Adding charset - patch for php_imap.c
This time the patch is actually attached...
Attached is a suggested patch to make it possible to set the CHARSET parameter with
imap_mail_compose(). Currently, all body parts with Content-Type = TYPETEXT get
CHARSET=US-ASCII.
Usage:
$body[1][type] = TYPETEXT;
$body[1][charset] = iso-8859-1;
Chuck, if there are no objections to the patch, can you commit it?
Best regards,
/Johan Ekenberg
--- php_imap.c.bak Fri May 4 19:47:01 2001
+++ php_imap.c Wed May 16 23:18:56 2001
@@ -3255,6 +3255,14 @@
convert_to_long_ex(pvalue);
bod-encoding = (short) Z_LVAL_PP(pvalue);
}
+ if (zend_hash_find(Z_ARRVAL_PP(data), charset, sizeof(charset),
+(void **) pvalue)== SUCCESS) {
+ convert_to_string_ex(pvalue);
+ tmp_param = mail_newbody_parameter();
+ tmp_param-value = cpystr(Z_STRVAL_PP(pvalue));
+ tmp_param-attribute = CHARSET;
+ tmp_param-next = bod-parameter;
+ bod-parameter = tmp_param;
+ }
if (zend_hash_find(Z_ARRVAL_PP(data), subtype, sizeof(subtype),
(void **) pvalue)== SUCCESS) {
convert_to_string_ex(pvalue);
bod-subtype = cpystr(Z_STRVAL_PP(pvalue));
@@ -3332,6 +3340,14 @@
if (zend_hash_find(Z_ARRVAL_PP(data), encoding,
sizeof(encoding), (void **) pvalue)== SUCCESS) {
convert_to_long_ex(pvalue);
bod-encoding = (short) Z_LVAL_PP(pvalue);
+ }
+ if (zend_hash_find(Z_ARRVAL_PP(data), charset,
+sizeof(charset), (void **) pvalue)== SUCCESS) {
+ convert_to_string_ex(pvalue);
+ tmp_param = mail_newbody_parameter();
+ tmp_param-value = cpystr(Z_STRVAL_PP(pvalue));
+ tmp_param-attribute = CHARSET;
+ tmp_param-next = bod-parameter;
+ bod-parameter = tmp_param;
}
if (zend_hash_find(Z_ARRVAL_PP(data), subtype,
sizeof(subtype), (void **) pvalue)== SUCCESS) {
convert_to_string_ex(pvalue);
--
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 #10908 Updated: Undeclared variables/URL declared variables
ID: 10908
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Scripting Engine problem
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
It's not open, it was not a bug, so closing.
Previous Comments:
---
[2001-05-16 17:36:31] [EMAIL PROTECTED]
Submitter added:
Oops! in the code in the above bug report, i made a mistake: Change
if($id=view) to if($id==view) Thats how the original code I ran looked like.
Sorry for the error, I was typing fast.
Your problem is simply that the error_level (as described by derick) is set higher
than you are used to. Still, the code should probably read something like
if (isset($id) ($id==view))
---
[2001-05-16 17:07:02] [EMAIL PROTECTED]
This is not a bug.
1. Use:
if ($id == view)
= : assignment
== : comparison
2. You can change your errorlevel, which is causing these
messages, see www.php.net/error_reporting
---
[2001-05-16 16:56:04] [EMAIL PROTECTED]
Ok, I ran this script on my Apache server with the new PHP 4.0.5 installed and it did
not work...
?
if($id=view){
echo You are in view mode;
}
else{
echo You are not in view mode;
?
br
form action=?id=view method=post
input type=submit value=Change to View Mode
/form
?
}
?
When you first view the page, it says You are not in view mode and has a submit
button that says Change to View Mode. If you click to button it will give $id the
value of view, so when it reloads the page, it will display You are in view mode.
This script works fine on my server with the earlier version of PHP, but not with
4.0.5. The new version 4.0.5 returns an error the first time it loads an says that $id
hasnt been defined.
I dont know if they changed it on the new version because they thought it was a bug of
the old versions(that didnt return errors for undeclared variables), but if thats the
case, they certainly disabled simple scripts like this one that made things a hell of
a lot easier for us programmers. Thats why I'm using the old version of PHP, and not
PHP 4.0.5 on my Apache server.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10908edit=2
--
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]
