[PHP-DEV] PHP 4.0 Bug #10176 Updated: configurable cgi parameter separators
ID: 10176 Updated by: joey Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Feature/Change Request Assigned To: Comments: Thank you. This is a known issue. 4.0.5 will have 2 ini parameters to deal with this: arg_separator.input arg_separator.output Read the php-dev archives for more info. :) Previous Comments: --- [2001-04-05 02:14:10] [EMAIL PROTECTED] It would be nice to have configurable cgi parameter separators for http get requests, because the commonly used sign doesn't fullfill the HTML specification. read more on this at: http://validator.w3.org/docs/errors.html#bad-entity It would be nice if this could be configured on a directory/server/virtual server basis in .htaccess or httpd.conf files maybe in the following way: php_value cgi_get_separator ; for ; as an example --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10176edit=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] PHP 4.0 Bug #10177: IIS 5.0 can not start with enabled mssql70 extension
From: [EMAIL PROTECTED] Operating system: Windows2000 Server PHP version: 4.0.4pl1 PHP Bug Type: MSSQL related Bug description: IIS 5.0 can not start with enabled mssql70 extension -- Edit Bug report at: http://bugs.php.net/?id=10177edit=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] Unix timestamp maximum
Ideally it should not depend an operating system structure. Agreed (but quite a lot of work I think). I propose #define PHP_DATE_SIZE _int64 Not agreed, unless you move the start date backwards a few thousand years :) Cheers -- Phil Driscoll Dial Solutions +44 (0)113 294 5112 http://www.dialsolutions.com http://www.dtonline.org -- 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-CVS] cvs: php4 / NEWS php.ini-dist php.ini-optimized /ext/standard url_scanner.c url_scanner_ex.c url_scanner_ex.re /main main.cphp_globals.h php_variables.c
On Wed, 4 Apr 2001, Jani Taskinen wrote: sniperWed Apr 4 13:46:27 2001 EDT Modified files: /php4 php.ini-dist php.ini-optimized NEWS /php4/ext/standardurl_scanner.c url_scanner_ex.re url_scanner_ex.c /php4/mainmain.c php_globals.h php_variables.c Log: Added new configuration directives: arg_separator.input and arg_separator.output Am I the only one who thinks that breaking installations which use a different arg_separator is odd? Now all those working installations have to be manually modified just to append ".output". - 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] Unix timestamp maximum
Hi Stanislav! On Wed, 04 Apr 2001, Stanislav Malyshev wrote: AG By the time we close in on 2038 and UNIX is still around AG (*smile*) then most UNIX systems will most probably have moved AG to 64bit timestamps, thus requiring in the best place just a AG recompilation of your PHP binary and in the worse case if you AG saved binary file stamps to a file, some kind of conversion AG script. It's not as bad as the Y2K bug (which wasn't too bad:) Well, seeing that most Unix concepts are alive from 60-70th till today, they'll probably be there in 2038. And I'm not sure all systems will be upgraded by then. But I would probably be retired already by then, so why should I care? ;) Haven't you seen "Cowboys in space?" you will be called back to save the world from Y-0x07f6 Bug! :)) -- teodor -- 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 Bug #10177 Updated: IIS 5.0 can not start with enabled mssql70 extension
ID: 10177 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: MSSQL related Assigned To: Comments: Please provide more information, about what error's you get, the output of your phpino(); (on a website if that's possible) and your php.ini file (and the location on your filesystem of it). Previous Comments: --- [2001-04-05 03:42:20] [EMAIL PROTECTED] --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10177edit=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] PHP 4.0 Bug #10171 Updated: calling function before it is defined only works in same file
ID: 10171 Updated by: cynic Reported By: [EMAIL PROTECTED] Status: Open Old-Bug Type: Scripting Engine problem Bug Type: Documentation problem Assigned To: Comments: problem here is that include()s require()s are runtime thingies. I got bitten by this just yesterday: if you e. g. redeclare a function in a require()d file, the 'fatal error: function redeclaration...' does appear, but at runtime, not during compilation. Anyway, this is what Andi told me on the subject: The main reason [require() was changed to happen at run time rather than at compile time] was that it was supposed to improve performance and it didn't. It actually tended to slow things down. Removing this also allowed us to reduce the memory usage of PHP scripts (not as important). (...) It really sucked and we managed to clean up some code and internals due to taking it out. I wouldn't want to put it back in. So, this is by design. - docuprob Previous Comments: --- [2001-04-04 19:05:28] [EMAIL PROTECTED] Define a function. Put a call to that function BEFORE it is defined. That works, as documented. Now put the function in an include()'d or require()'d file. Call the function before the include() or require(). It fails. Since the code is pre-compiled beforehand, shouldn't the function calls still work? If this is "as designed" it might be nice to place a caveat in the documentation that states "you can call a function before you define it ONLY if the function isn't buried in an include()." --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10171edit=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] 4.0.5 Comments change (leads to inappropriate parse error based on contents of comments)
hi there,
actually, the behavior you experienced with previous versions
was buggy. current behavior is correct (and matches documentation,
which has claimed this behavior for long).
At 02:54 5.4. 2001, Steven Roussey wrote the following:
--
Hi,
I found our problem. In 4.0.5, comments seem to be parsed differently. We
have ASP style tags enabled so we can use % as well as ?. But we had
comments like this:
?
//asdfasdf%asdfasdf
echo('');
?
4.0.5 would ignore the whole line. 4.0.5 still parses it for open and
close tags. The lines above get handled differently from 4.0.4 to 4.0.5. It
is hard to track if the comment is inside a class, because there is no parse
error until the end of the file, and the code is not spit out like HTML (as
in the example above) because it is compiling the file. I think this is a
bug. We can clean up our code to fix it (and will), but
Sincerely,
Steven Roussey
Network54.com
http://network54.com/?pp=e
--
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]
--end of quote--
[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]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / NEWS php.ini-dist php.ini-optimized /ext/standard url_scanner.c url_scanner_ex.c url_scanner_ex.re /main main.c php_globals.h php_variables.c
IIRC both these directives default to '', right? So it'll still work even if you don't edit you php.ini. Or am I missing something? At 10:22 5.4. 2001, Sascha Schumann wrote the following: -- On Wed, 4 Apr 2001, Jani Taskinen wrote: sniperWed Apr 4 13:46:27 2001 EDT Modified files: /php4 php.ini-dist php.ini-optimized NEWS /php4/ext/standardurl_scanner.c url_scanner_ex.re url_scanner_ex.c /php4/mainmain.c php_globals.h php_variables.c Log: Added new configuration directives: arg_separator.input and arg_separator.output Am I the only one who thinks that breaking installations which use a different arg_separator is odd? Now all those working installations have to be manually modified just to append ".output". - 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] --end of quote-- [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] PHP 4.0 Bug #10178: Configuration of extensions
From: [EMAIL PROTECTED] Operating system: Windows2000/IIS5 PHP version: 4.0.4pl1 PHP Bug Type: *Install and Config Bug description: Configuration of extensions I always get a message like cannot find module 'c:\php\extensions\php_ldap.dll' i have tried '/' instead of '\'. Actually I have tried everything.WHAT CAN I DO SAVE ME PLEASEEE! I am currently working on an academic project and if this does not get solved I will have to change to ASP...please do not do this to me! regards mike -- Edit Bug report at: http://bugs.php.net/?id=10178edit=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] PHP 4.0 Bug #10177 Updated: IIS 5.0 can not start with enabled mssql70 extension
ID: 10177 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: MSSQL related Description: IIS 5.0 can not start with enabled mssql70 extension Steps I do: 1. PHP is working as an ISAPI without mssql70 extension. In php.ini: ;extension=php_mssql70.dll 2. Set in php.ini mssql70 extension: extension=php_mssql70.dll 3. When I try to restart World Wide Web Publishing Service it displays an error message - Service cannot be started and its status goes 'Starting' 4. If I disable mssql70 extension in php.ini and reboot computer, PHP works again. Previous Comments: --- [2001-04-05 05:02:35] [EMAIL PROTECTED] Please provide more information, about what error's you get, the output of your phpino(); (on a website if that's possible) and your php.ini file (and the location on your filesystem of it). --- [2001-04-05 03:42:20] [EMAIL PROTECTED] --- Full Bug description available at: http://bugs.php.net/?id=10177 -- 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 Bug #10179: repetition quantifiers
From: [EMAIL PROTECTED]
Operating system: SuSE7.0
PHP version: 4.0.4pl1
PHP Bug Type: PCRE related
Bug description: repetition quantifiers
I am not sure if it's a bug or misinterpretation on my side
but I expect something like /[0-9]{,10}/ to match
a number at most 10 chars.
the following snipet reproduces the "problem", if any:
if (preg_match('/^[0-9]{,10}$/',3)) {
echo "matched";
} else {
echo "not matched";
}
outputs "not matched".
And if I write {1,10} it matches. So the question is,
is the "minimum" quantifier mandatory?
ciao
--
Edit Bug report at: http://bugs.php.net/?id=10179edit=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] PHP 4.0 Bug #10180: date arithmetic gives wrong result
From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version: 4.0.4pl1
PHP Bug Type: Date/time related
Bug description: date arithmetic gives wrong result
?
$birthdate = mktime(0, 0, 0, 1, 1, 2001);
// should give 82 days old - correct
$CurDate = mktime(0,0,0,3,24,2001);
printf("BR".date("z", $CurDate - $birthdate ) ." days old");
// should give 83 days old - correct
$CurDate = mktime(0,0,0,3,25,2001);
printf("BR".date("z", $CurDate - $birthdate ) ." days old");
// should give 84 days old - instead gives 83
$CurDate = mktime(0,0,0,3,26,2001);
printf("BR".date("z", $CurDate - $birthdate ) ." days old");
// should give 85 days old - instead gives 84
$CurDate = mktime(0,0,0,3,27,2001);
printf("BR".date("z", $CurDate - $birthdate ) ." days old");
?
--
Edit Bug report at: http://bugs.php.net/?id=10180edit=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] PHP 4.0 Bug #10180 Updated: date arithmetic gives wrong result
ID: 10180
Updated by: ab
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Date/time related
Assigned To:
Comments:
daylight saving time started on 3.26.2001 so behaviour is correct
Previous Comments:
---
[2001-04-05 05:44:20] [EMAIL PROTECTED]
?
$birthdate = mktime(0, 0, 0, 1, 1, 2001);
// should give 82 days old - correct
$CurDate = mktime(0,0,0,3,24,2001);
printf("BR".date("z", $CurDate - $birthdate ) ." days old");
// should give 83 days old - correct
$CurDate = mktime(0,0,0,3,25,2001);
printf("BR".date("z", $CurDate - $birthdate ) ." days old");
// should give 84 days old - instead gives 83
$CurDate = mktime(0,0,0,3,26,2001);
printf("BR".date("z", $CurDate - $birthdate ) ." days old");
// should give 85 days old - instead gives 84
$CurDate = mktime(0,0,0,3,27,2001);
printf("BR".date("z", $CurDate - $birthdate ) ." days old");
?
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10180edit=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] PHP 4.0 Bug #10136 Updated: Function mail() does not work properly
ID: 10136
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Mail related
Description: Function mail() does not work properly
OK, I found the problem, folks !!
If you want to send messages in Cc: and Bcc: and personnalize to name of the To:
recipients, I found a topic in newsgroup, you have to :
put all adresses (including To:, Cc: and Bcc: adress) in the $to field of mail
function and then in the header, you put in to: bcc: and cc: the correct adresses...
By this way, the mail function will properly put the adresses in the right fields,
example :
$to = "[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]"
$from = "Test PHP [EMAIL PROTECTED]\n";
$headers = "To: Nono [EMAIL PROTECTED]\n";
$headers .= "cc: Admin CEnet [EMAIL PROTECTED]\n";
$headers .= "Bcc: Hidden test [EMAIL PROTECTED]";
mail ($to,"my subject","my (nice !) body","From: $from".$headers);
It works...
But now the real bug (yes it is !!) is when typing "Cc:" instead of "cc:" = It looks
like there's a emalloc error allocating -875642131 bytes (the number is not ever the
same)... Think I'll open a new bug entry !!!
Previous Comments:
---
[2001-04-04 03:20:25] [EMAIL PROTECTED]
Seems to work but i need to put addresses between for mail from: and rcpt to:
fields...
---
[2001-04-03 17:25:29] [EMAIL PROTECTED]
i'd suggest one thing - try this (it will give more light if the problem is in your
mailserver):
telnet localhost 25
helo there
mail from: [EMAIL PROTECTED]
rcpt to: [EMAIL PROTECTED]
data
from: "your name" [EMAIL PROTECTED]
to: "name 1" [EMAIL PROTECTED], "name 2" [EMAIL PROTECTED], [EMAIL PROTECTED]
subject: some subject
some nice body
---
[2001-04-03 09:57:57] [EMAIL PROTECTED]
First, I tried making mail() function work() on a Win2k - IIS 5.0 server and on
Win98SE - Apache 1.3.19 both with PHP 4.0.4pl1.
there are several things wrong (so far it wouldn't be me the problem ;-) ) :
- first :
mail ("Arnaud [EMAIL PROTECTED]","A subject here","A message body here",...);
(as mentioned in PHP manual), It won't work, i have a "Warning: Server error on
blabla.php3:lineXX" but if the "To:" Field is replace by just an email adress :
mail("[EMAIL PROTECTED]",); this would work... So I can't send mails with the name
of the recipients properly set (just their email adress)...
NB: Multiple "To:" Recipients works but only with email adresses
That's not the most important problem for me, the most important is Cc: and Bcc: won't
work.
The manual mentions to add From: Cc: and Bcc: information, in the fourth parameters
(the headers)... So I tried :
mail("[EMAIL PROTECTED]","A subject here","A (very nice !) body here","From: The
Administrator [EMAIL PROTECTED]nBcc: My Friend [EMAIL PROTECTED]nCc: My Father
[EMAIL PROTECTED]");
it obviously doesn't work :-(( (that's why I'm writing you !!)
There are several things to say :
- The From: section of headers works well, nothing to say about it... No problem
- Seems the Bcc: part is just ignored, nothing happen, no mail is sent to Bcc: address
- For Cc:, when typed "cc:" (all lowercase) seems to be ignored but when typed "Cc:"
= It looks like there is a memory leak or something like that both IIS and Apache
return me a "emalloc() : unable to allocate -851230 bytes"... The number of
unallocated bytes is not ever the same but this is the same error message...
Extra info :
- On both config, the mail server is a local mail server (FTGate 2.2.2.1)
- It seems that this bug is similar to #9858 and #9859 in the bug database
---
Full Bug description available at: http://bugs.php.net/?id=10136
--
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 Bug #10181: odbc_result causes Unexpected network read error
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.0.4pl1
PHP Bug Type: ODBC related
Bug description: odbc_result causes Unexpected network read error
Configuration bulld with
'./configure' '--with-openlink=/opt' '--sysconfdir=/etc'
'--with-apxs=/var/lib/apache/sbin/apxs'
Problem also occures when using --with-iodbc
The database I connect to is a Progress 7.3E15 database. Using the odbctest program
all works fine: i.e. it does not seem to be a problem with the openlink or iodbc code.
This is the code that results in the error
HTML
HEAD
TITLEQuery ps_mstr/TITLE
/HEAD
BODY
?php
$part = '9450001';
putenv("LD_LIBRARY_PATH=/opt/odbcsdk/lib");
putenv("ODBCINI=/etc/odbc.ini");
$dsn = "DSN=qaddb";
$sql = "select ps_comp from ps_mstr where ps_par = '$part'";
echo "PQuery is $sql/P\n";
if ($conn_id = odbc_connect("$dsn","","")) {
echo "PDatabase connection succeeded/P\n";
if ($result = odbc_do($conn_id, "$sql")) {
echo "PQuery succesfully submitted/P\n";
/*
odbc_result_all($result);
*/
while (odbc_fetch_row($result)) {
$comp = odbc_result($result, 1);
echo "P$comp/P\n";
}
odbc_free_result($result);
} else {
echo "PProblem submitting query/P\n";
}
odbc_close($conn_id);
} else {
}
?
Using lynx as a browser, I get the following errors:
Alert!: Unexpected network read error; connection aborted.
The code works fine if I give $part the value "STRATOS". It seems that the code breaks
when the query looks for records with key values that start with a number _and_ when
more than one row is being returned.
odbc_result_all also gives strange. The output with odbc_result_all and $part =
9450001 looks like:
ps_comp
Openlink_DSN=qaddb___2
Openlink_DSN=qaddb___2
Openlink_DSN=qaddb___2
Openlink_DSN=qaddb___2
Openlink_DSN=qaddb___2
The php.ini file is the same as php.ini-dist expect for output buffering being enabled.
Hope this helps
TIA
Frans Schneider
work: [EMAIL PROTECTED]
home: [EMAIL PROTECTED]
--
Edit Bug report at: http://bugs.php.net/?id=10181edit=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] RE: PHP 4.0 Bug #10157 Updated: fdf_next_field_name still not work.
Hi! Works perfect now! I stumbled into another problem though. fdf_get_status won't give me the /STATUS-key from the FDF file. I open the fdf file with $foo = fdf_open($fp); and then echo fdf_get_status($foo); and it just returns a (square). When i print out the fdf file I can clearly see the /STATUS-key, so it's there. btw: fdf_set_status works perfect. /Stefan. -Original Message- From: Bug Database [mailto:[EMAIL PROTECTED]] Sent: den 5 april 2001 07:46 To: [EMAIL PROTECTED] Subject: PHP 4.0 Bug #10157 Updated: fdf_next_field_name still not work. ID: 10157 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: FDF related Assigned To: Comments: Fixed in CVS now. Thank you for reminding me.. :) --Jani Previous Comments: --- [2001-04-04 08:50:12] [EMAIL PROTECTED] fdf_next_field_name still won't return any strings what so ever.. (see bug #7549) ?? --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10157edit=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] app server
Hello, I'm Calin from Romania. I've worked with php for about 1 year. I am wondering, to this lack in PHP: the application server part, what solutions have you found to make objects, arrays, variables, database templates 'live' into the server? Do you have any ideas what direction will PHP follow to ease this into the core? Regards, Calin -- 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 Bug #9832 Updated: httpd memory problem with informix
ID: 9832 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: Informix related Description: httpd memory problem with informix Previous Comments: --- [2001-03-19 04:58:55] [EMAIL PROTECTED] After successfully getting data from an Informix IDS2000 Database the httpd never frees his used memory. (After a big select the httpd's memory will rise about 40 MB). - the httpd's eat all available system memory and swap, resulting in an system crash (VM: killing...). The httpd got up to 300 MB RSS. Thanks for your help Torsten systems affected: SuSE Linux 2.2.14, apache 2.2.14, php4.03pl1 SuSE Linux 2.2.16, apache 2.2.17, php4.03pl1 Linux 2.2.18, apache 2.2.19, php4.03pl1 Configure command- line: ./configure --enable-safe-mode --enable-sysvsem --enable-sysvshm --with-zlib --with-gd=/usr --with-yp --with-jpeg-dir --with-tiff-dir=/usr/lib --with-config-file-path=/etc/httpd --with-png-dir --with-exec-dir=/usr/lib/apache/bin --with-apache=../apache_1.3.17 --with-informix=/opt/informix --with-pdflib --- Full Bug description available at: http://bugs.php.net/?id=9832 -- 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 Bug #10182: problem with the To field
From: [EMAIL PROTECTED] Operating system: Windows 98 - 2 PHP version: 4.0.4pl1 PHP Bug Type: Mail related Bug description: problem with the "To" field Ok, I have found several notes telling that the following syntax works : $to = "\"Arnaud PERE\" [EMAIL PROTECTED]"; mail ($to,"subject","message"); But when I try this, my SMTP server says : (bad host/domain syntax: "agilitime.com") see the trailing ""... Instead, I tried the following syntax which appeared to work : $to = "[EMAIL PROTECTED] (Arnaud PERE)"; mail ($to,"subject","message"); This problem does not appear on the Unix version of PHP4.04pl1, but only on the windows version. Did I do something wrong ? -- Edit Bug report at: http://bugs.php.net/?id=10182edit=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] PHP 4.0 Bug #10183: W2K, IIS Access violation (ISAPI)
From: [EMAIL PROTECTED] Operating system: W2K PHP version: 4.0.4pl1 PHP Bug Type: IIS related Bug description: W2K, IIS Access violation (ISAPI) The CGI version is OK but the isapi gives me the folowing error PHP has encountered an Access Violation at 0B292466 With any kind of code with or without db connection. (eg phpinfo() i a page) Thanks in advance for your help -- Edit Bug report at: http://bugs.php.net/?id=10183edit=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] Re: [PHP-CVS] cvs: php4 / NEWS php.ini-dist php.ini-optimized /ext/standard url_scanner.c url_scanner_ex.c url_scanner_ex.re /main main.c php_globals.h php_variables.c
At 10:22 AM 4/5/2001 +0200, Sascha Schumann wrote: On Wed, 4 Apr 2001, Jani Taskinen wrote: sniperWed Apr 4 13:46:27 2001 EDT Modified files: /php4 php.ini-dist php.ini-optimized NEWS /php4/ext/standardurl_scanner.c url_scanner_ex.re url_scanner_ex.c /php4/mainmain.c php_globals.h php_variables.c Log: Added new configuration directives: arg_separator.input and arg_separator.output Am I the only one who thinks that breaking installations which use a different arg_separator is odd? Now all those working installations have to be manually modified just to append ".output". Considering the ambiguity I think it is the right thing to do. The default behavior will be backwards compatible and we can have a big caps news entry about it (for people who changed arg_separator). We could also keep arg_separator as an INI parameter in 4.0.5 and raise an error with a message on how to fix it (changing arg_separator to arg_separator.output). Andi 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]
[PHP-DEV] PHP 4.0 Bug #10184 Updated: Define and empty multi line string fault
ID: 10184
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Strings related
Description: Define and empty multi line string fault
Previous Comments:
---
[2001-04-05 10:16:52] [EMAIL PROTECTED]
CODE USED-
$var = EOF
EOF;
define("CONSTANT", $var) ;
ERROR PRODUCED -
Warning: Constants may only evaluate to scalar values in
/home/sites/site5/cnf/lib2.cnf on line 26
The empty multi-line string does not evaluate to the same thing as:
$var = "";
Bug? Fault? User just being thick?
---
Full Bug description available at: http://bugs.php.net/?id=10184
--
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 Bug #10185: compile fails when using --with-oci8
From: [EMAIL PROTECTED] Operating system: IRIX 6.5 PHP version: 4.0.4pl1 PHP Bug Type: Compile Failure Bug description: compile fails when using --with-oci8 When I try to compile with oci8 support, I get an error. ORACLE Release is 8.1.5.0.1 Here is my ./configure command, and the output from make #./configure --prefix=/tmp/php/php4 --with-config-file-path=/tmp/php/php4/conf --with-oci8 #make Making all in . gcc -I. -I/export/tmp/php/php-4.0.4pl1/ -I/export/tmp/php/php-4.0.4pl1/main -I/export/tmp/php/php-4.0.4pl1 -I/export/tmp/php/php-4.0.4pl1/Zend -I/export/tmp/php/php-4.0.4pl1/ext/mysql/libmysql -I/packages/run/oracle81/OraHome1/rdbms/demo -I/packages/run/oracle81/OraHome1/network/public -I/packages/run/oracle81/OraHome1/plsql/public -I/export/tmp/php/php-4.0.4pl1/ext/xml/expat/xmltok -I/export/tmp/php/php-4.0.4pl1/ext/xml/expat/xmlparse -I/export/tmp/php/php-4.0.4pl1/TSRM -DXML_BYTE_ORDER=21 -g -O2 -c stub.c touch stub.lo /bin/sh /export/tmp/php/php-4.0.4pl1/libtool --silent --mode=link gcc -I. -I/export/tmp/php/php-4.0.4pl1/ -I/export/tmp/php/php-4.0.4pl1/main -I/export/tmp/php/php-4.0.4pl1 -I/export/tmp/php/php-4.0.4pl1/Zend -I/export/tmp/php/php-4.0.4pl1/ext/mysql/libmysql -I/packages/run/oracle81/OraHome1/rdbms/demo -I/packages/run/oracle81/OraHome1/network/public -I/packages/run/oracle81/OraHome1/plsql/public -I/export/tmp/php/php-4.0.4pl1/ext/xml/expat/xmltok -I/export/tmp/php/php-4.0.4pl1/ext/xml/expat/xmlparse -I/export/tmp/php/php-4.0.4pl1/TSRM -DXML_BYTE_ORDER=21 -g -O2 -o libphp4.la -rpath /export/tmp/php/php-4.0.4pl1/libs -L/packages/run/oracle81/OraHome1/lib -R /packages/run/oracle81/OraHome1/lib stub.lo Zend/libZend.la sapi/cgi/libsapi.la main/libmain.la regex/libregex.la ext/mysql/libmysql.la ext/oci8/liboci8.la ext/pcre/libpcre.la ext/posix/libposix.la ext/session/libsession.la ext/standard/libstandard.la ext/xml/libxml.la TSRM/libtsrm.la -ldl -lm -lexc -lgen -lm -ldl -lcrypt -lsocket -lsocket -lclntsh /bin/sh /export/tmp/php/php-4.0.4pl1/libtool --silent --mode=link gcc -I. -I/export/tmp/php/php-4.0.4pl1/ -I/export/tmp/php/php-4.0.4pl1/main -I/export/tmp/php/php-4.0.4pl1 -I/export/tmp/php/php-4.0.4pl1/Zend -I/export/tmp/php/php-4.0.4pl1/ext/mysql/libmysql -I/packages/run/oracle81/OraHome1/rdbms/demo -I/packages/run/oracle81/OraHome1/network/public -I/packages/run/oracle81/OraHome1/plsql/public -I/export/tmp/php/php-4.0.4pl1/ext/xml/expat/xmltok -I/export/tmp/php/php-4.0.4pl1/ext/xml/expat/xmlparse -I/export/tmp/php/php-4.0.4pl1/TSRM -DXML_BYTE_ORDER=21 -g -O2 -o php -export-dynamic stub.lo libphp4.la ld32: WARNING 84 : /usr/lib32/libdl.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libexc.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libgen.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libsocket.so is not used for resolving any symbol. ld32: FATAL 12 : Expecting n32 objects: /packages/run/oracle81/OraHome1/lib/libclntsh.so is n64. collect2: ld returned 4 exit status *** Error code 1 (bu21) *** Error code 1 (bu21) -- Edit Bug report at: http://bugs.php.net/?id=10185edit=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] PHP 4.0 Bug #10186: Apache cannot load libphp4.so symbol ap_block_alarms
From: [EMAIL PROTECTED] Operating system: SunOS pisun7 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra-2 PHP version: 4.0.4pl1 PHP Bug Type: Apache related Bug description: Apache cannot load libphp4.so symbol ap_block_alarms # ./apachectl start Syntax error on line 205 of /opt/apache/conf/httpd.conf: Cannot load /opt/apache/libexec/libphp4.so into server: ld.so.1: /opt/apache/bin/httpd: fatal: relocation error: file /opt/apache/libexec/libphp4.so: symbol ap_block_alarms: referenced symbol not found ./apachectl start: httpd could not be start # ldd httpd libpthread.so.1 = /usr/lib/libpthread.so.1 libsocket.so.1 =/usr/lib/libsocket.so.1 libnsl.so.1 = /usr/lib/libnsl.so.1 libc.so.1 = /usr/lib/libc.so.1 libdl.so.1 =/usr/lib/libdl.so.1 libmp.so.2 =/usr/lib/libmp.so.2 libthread.so.1 =/usr/lib/libthread.so.1 # ldd libphp4.so libpam.so.1 = /usr/lib/libpam.so.1 libdl.so.1 =/usr/lib/libdl.so.1 libresolv.so.2 =/usr/lib/libresolv.so.2 libm.so.1 = /usr/lib/libm.so.1 libsocket.so.1 =/usr/lib/libsocket.so.1 libc.so.1 = /usr/lib/libc.so.1 libnsl.so.1 = /usr/lib/libnsl.so.1 libmp.so.2 =/usr/lib/libmp.so.2 Server version: Apache/1.3.19 (Unix) compiled from source. -- Edit Bug report at: http://bugs.php.net/?id=10186edit=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] PHP 4.0 Bug #10187 Updated: Warning: mcrypt module initialization failed
ID: 10187 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Analyzed Bug Type: mcrypt related Assigned To: derick Comments: Another mcrypt bug, I'll check this one out. It may be a platform depended bug BTW. Previous Comments: --- [2001-04-05 11:29:52] [EMAIL PROTECTED] First, the "--disable-posix-threads" requirement for libmcrypt isn't a requirement anymore. As of libmcrypt 2.4.x, you don't need it. Second, I think you should be using the 2.4.x-style mcrypt functions. Look at example 2 at http://www.php.net/manual/en/ref.mcrypt.php Third, blowfish is broken in libmcrypt. It will encode/decode internally, but don't rely on it if you need to pass data to a non-PHP application (e.g. Perl). - Colin --- [2001-04-05 11:24:02] [EMAIL PROTECTED] Using libmcrypt-2.4.10 on Mac OS X 10.0, compiled with --with-apache=/usr/local/src/apache_1.3.19 --with-mysql=/ usr/local --with-mcrypt --enable-track-vars --disable-debug My sample script: ?php $stuff = mcrypt_cbc(MCRYPT_BLOWFISH,"This is my key","this is my message",MCRYPT_ENCRYPT); print base64_encode($stuff); ? produces this error: Warning: mcrypt module initialization failed in /Users/ clewis/dev/website/public/asdf.php on line 3 libmcrypt was compiled with --disable-posix-threads as suggested on the PHP mcrypt page. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10187edit=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] PHP 4.0 Bug #10187 Updated: Warning: mcrypt module initialization failed
ID: 10187 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Analyzed Status: Assigned Bug Type: mcrypt related Assigned To: derick Comments: analysed assigned Previous Comments: --- [2001-04-05 11:30:06] [EMAIL PROTECTED] Another mcrypt bug, I'll check this one out. It may be a platform depended bug BTW. --- [2001-04-05 11:29:52] [EMAIL PROTECTED] First, the "--disable-posix-threads" requirement for libmcrypt isn't a requirement anymore. As of libmcrypt 2.4.x, you don't need it. Second, I think you should be using the 2.4.x-style mcrypt functions. Look at example 2 at http://www.php.net/manual/en/ref.mcrypt.php Third, blowfish is broken in libmcrypt. It will encode/decode internally, but don't rely on it if you need to pass data to a non-PHP application (e.g. Perl). - Colin --- [2001-04-05 11:24:02] [EMAIL PROTECTED] Using libmcrypt-2.4.10 on Mac OS X 10.0, compiled with --with-apache=/usr/local/src/apache_1.3.19 --with-mysql=/ usr/local --with-mcrypt --enable-track-vars --disable-debug My sample script: ?php $stuff = mcrypt_cbc(MCRYPT_BLOWFISH,"This is my key","this is my message",MCRYPT_ENCRYPT); print base64_encode($stuff); ? produces this error: Warning: mcrypt module initialization failed in /Users/ clewis/dev/website/public/asdf.php on line 3 libmcrypt was compiled with --disable-posix-threads as suggested on the PHP mcrypt page. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10187edit=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] PHP 4.0 Bug #10188: Problem in loading dynamic module (Desc. below)
From: [EMAIL PROTECTED] Operating system: Linux Mandrake PHP version: 4.0.4pl1 PHP Bug Type: Dynamic loading Bug description: Problem in loading dynamic module (Desc. below) Apache 1.3.19 is configured with --enable-module=all --enable-shared=max php-4.0.4pl1 is configured with ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-config-file-path=/usr/local/apache --enable-shared After running "make" "make install" without any errors, then I run "apachectl configtest" and it outputs the error: "API module structure `php4_module' in file /usr/local/apache/libexec/libphp4.so is garbled - perhaps this is not an Apache module DSO?" -- Edit Bug report at: http://bugs.php.net/?id=10188edit=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] RE: ; arg seperator
Quoting Hartmut Holzgraefe [EMAIL PROTECTED]: arg_separator.output should default to 'nbsp;'. nbsp; ??? i guess it will break lots ;) maybe we should amp; instead? Wow. Yeah, I'm really tired this morning. amp; is what I meant, of course... Thanks, Hartmut. :) -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Number of U.S. nuclear bombs lost in accidents and never recovered: 11 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug in latest CVS?? Autoconf
I got this after I d/l'd the CVS: [root@voyager php4]# ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) buildconf: libtool version 1.3.5 (ok) rebuilding Makefile templates automake: configure.in: installing `Zend/ylwrap' rebuilding configure autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH ***BUG in Autoconf--please report*** AC_ADD_INCLUDE rebuilding acconfig.h rebuilding main/php_config.h.in -- 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 in latest CVS?? Autoconf
On Thu, Apr 05, 2001 at 12:12:04PM -0400, Greg Kopp wrote: I got this after I d/l'd the CVS: [root@voyager php4]# ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) buildconf: libtool version 1.3.5 (ok) rebuilding Makefile templates automake: configure.in: installing `Zend/ylwrap' rebuilding configure autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH ***BUG in Autoconf--please report*** AC_ADD_LIBRARY ***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH ***BUG in Autoconf--please report*** AC_ADD_INCLUDE rebuilding acconfig.h rebuilding main/php_config.h.in Did it right now with latest CVS, nothing wrong, all was build finely. -- Sincerely yours, Alexander Bokovoy The Midgard Project| ALT Linux Team | Minsk Linux Users Group www.midgard-project.org | www.altlinux.ru |www.minsk-lug.net -- It is your destiny. - Darth Vader -- 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 Bug #10189: apache UnsetEnv does not work, possibly effecting php scripts
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.3-RC PHP version: 4.0.4pl1 PHP Bug Type: Apache related Bug description: apache UnsetEnv does not work, possibly effecting php scripts a bug report was submitted to apache: http://bugs.apache.org/index.cgi/full/7528 basically, the UnsetEnv directive in apache does not actually delete variables from the environment. a fix is included in the above bug report. -- Edit Bug report at: http://bugs.php.net/?id=10189edit=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] 4.0.5 Comments change (leads to inappropriate parseerror based on contents of comments)
OK.
Here is an example of why it causes problems: We had some lines of code like
this:
echo ("table width=100%");
works ok. But then we comment out the that line:
// echo ("table width=100%");
it now dies.
You might make a note in the NEWS section if it is not already there. I'll
get everyone here to hand convert all the ASP tags to more PHP like tags
(and maybe eliminate short tags too) and then turn those options off so the
(very common) scenario above doesn't drive people nuts later...
Sincerely,
Steven Roussey
Network54.com
http://network54.com/?pp=e
This was fixed to be consistent with ?.
One line comments end at a new line or at a closing bracket (? or %)
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]
[PHP-DEV] PHP 4.0 Bug #10190: \t$var = EOI\n\tblah\tEOI;
From: [EMAIL PROTECTED] Operating system: any PHP version: 4.0.4pl1 PHP Bug Type: Feature/Change Request Bug description: \t$var = lt;lt;lt;EOI\n\tblah\tEOI; $var = EOI blah EOI; I would like to have the EOI syntax ignore whitespace when finding the EOI; line It would make code pretty! :) Eric -- Edit Bug report at: http://bugs.php.net/?id=10190edit=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] 4.0.5 Comments change (leads to inappropriateparse error based on contents of comments)
Andi Gutmans wrote:
This was fixed to be consistent with ?.
One line comments end at a new line or at a closing bracket (? or %)
At 05:54 PM 4/4/2001 -0700, Steven Roussey wrote:
I found our problem. In 4.0.5, comments seem to be parsed differently. We
have ASP style tags enabled so we can use % as well as ?. But we had
comments like this:
?
//asdfasdf%asdfasdf
echo('');
?
but a code block should end with the sort of tag it started with
or are things like "? some code %" considered legal ???
--
Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77
--
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 Bug #9105 Updated: Incorrect path used
ID: 9105 Updated by: sterling Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Sablotron XSL Assigned To: sterling Comments: Relative paths don't work with windows. Previous Comments: --- [2001-02-05 02:46:17] [EMAIL PROTECTED] I'm using the following script ?php $p = xslt_create(); $res = xslt_run($p, "test.xsl","test.xml"); if(!$res) echo xslt_error($p); echo xslt_fetch_result($p); xslt_free($p); ? The files test.xml and test.xsl are in the same directory as the script, but PHP searches for them in the directory that contains my PHP/CGI php.exe. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9105edit=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] PHP 4.0 Bug #10191: file missing
From: [EMAIL PROTECTED] Operating system: NT PHP version: 4.0.4pl1 PHP Bug Type: Apache related Bug description: file missing File PEAR.php and all the structure is missing from the NT port. -- Edit Bug report at: http://bugs.php.net/?id=10191edit=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] PHP 4.0 Bug #10191 Updated: file missing
ID: 10191 Updated by: hholzgra Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Apache related Assigned To: Comments: there is no such thing as a *NT port*, all versions of PHP for different systems/platforms are built from the same source you are most likely refering to a special precompiled distribution of PHP for Windows? it might help if you gave us the link you got it from Previous Comments: --- [2001-04-05 14:33:05] [EMAIL PROTECTED] File PEAR.php and all the structure is missing from the NT port. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10191edit=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] PHP 4.0 Bug #8834 Updated: crypt() starts from not random salt
ID: 8834 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Strings related Assigned To: Comments: This is most likely a Solaris specific issue as I can't reproduce this on Linux. Can you please include the output of this command in both Solaris 2.4 and 2.6 (in php4): # grep RAND main/php_config.h It might be that in both of those system the seed generator found is srand() which isn't so good as srandom() is. But I also found (with google :) that srandom() might not be that good either (in Solaris) so that leaves us with a problem. One solution might be that we run php_srand() in RINIT instead of MINIT when Solaris is used. --Jani Previous Comments: --- [2001-01-22 06:05:34] [EMAIL PROTECTED] PHP compiled as Apache module. Look like crypt() starts from not random salt. In case of my Solaris 2.4, first crypt() call always generates string starting from "IH". In case of Solaris 2.6 it always starts from "C.". Looks like in every instantiation of new Apache process PHP starts crypt from the same salt value. In the same process next crypt() calls look like they generate random strings, though. But next process restarts with the same value. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8834edit=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] PHP 4.0 Bug #10079 Updated: Header Function Within IF construct
ID: 10079
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Old-Bug Type: Scripting Engine problem
Bug Type: *General Issues
Assigned To:
Comments:
As this is a browser problem with only one browser and one
version of it - closed. It's a bug in IE 5.01 SP2 so
report it to Microsoft. IIRC they only support 5.5 now so
good luck.
--Jani
Previous Comments:
---
[2001-04-05 11:55:56] [EMAIL PROTECTED]
I did some more testing and have found that it is indeed browser related. MSIE 5.01
SP2 have the problem and 5.00 and 5.5 do not. Have you tested with this browser? Also,
why would PHP behave as it does? Is it a timing issue?
Dean
---
[2001-04-03 18:30:34] [EMAIL PROTECTED]
Yes, I double checked it and ServerType standalone is in my httpd.conf file.
If there is anything I can do to help you debug the problem, just let me know. If you
want you can dial in and see for your self. This is not a production server that I am
testing on, so we can do whatever to track this down.
The problem I'm having, is that I want to do some authentication but code that should
not execute is getting executed.
Dean
---
[2001-04-03 10:30:02] [EMAIL PROTECTED]
Try this script:
?php
if(!isset($PHP_AUTH_USER)) {
exec("");
header('WWW-Authenticate: Basic Realm="A Test R"');
header("HTTP/1.0 401 Unauthorized");
echo "boo";
} else {
echo "else";
}
?
I can't reproduce the problem you have.
--Jani
p.s. Are you sure that you have this in your httpd.conf:
ServerType standalone
---
[2001-04-03 09:31:00] [EMAIL PROTECTED]
I was able to get PHP-4.0.5 installed and I still have the same problem. Is there
anything else you would like me to try? Is this a bug or expected behaviour?
Thanks for help.
Dean
---
[2001-03-30 16:56:37] [EMAIL PROTECTED]
I guess I'm doing this right... I downloaded php4-200103301245.tar.gz. Unzipped,
untarred and configured using --with-mysql --with-apache --with-trans-sid
--enable-track-vars --enable-sysvsem --enable-sysvshm
All configured fine. But make is not making
I'm getting symbol referencing errors. It is quite possible that this version is not
quite ready for SCO OpenServer. If you want, I'll send you the debug.log file from the
make operation. I'm not sure if you even mess with installation problems of PHP in
this forum.
I have a question: Is the annomally I reported a bug in 4.0.4pl1 or is it just my
system?
Dean
---
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=10079edit=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] PHP 4.0 Bug #8834 Updated: crypt() starts from not random salt
ID: 8834 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: Strings related Description: crypt() starts from not random salt here you are: Solaris 2.4: # grep RAND main/php_config.h #define HAVE_LRAND48 1 #define HAVE_RAND_R 1 /* #undef HAVE_RANDOM */ #define HAVE_SRAND48 1 /* #undef HAVE_SRANDOM */ # uname -a SunOS helios 5.4 Generic_101945-60 sun4d sparc # Solaris 2.6 # grep RAND main/php_config.h #define HAVE_LRAND48 1 #define HAVE_RAND_R 1 #define HAVE_RANDOM 1 #define HAVE_SRAND48 1 #define HAVE_SRANDOM 1 # uname -a SunOS uranos 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-4 # unfortunately I'm not able to discuss the solution, although I can test the one provided :-)), thank you Previous Comments: --- [2001-04-05 14:57:44] [EMAIL PROTECTED] This is most likely a Solaris specific issue as I can't reproduce this on Linux. Can you please include the output of this command in both Solaris 2.4 and 2.6 (in php4): # grep RAND main/php_config.h It might be that in both of those system the seed generator found is srand() which isn't so good as srandom() is. But I also found (with google :) that srandom() might not be that good either (in Solaris) so that leaves us with a problem. One solution might be that we run php_srand() in RINIT instead of MINIT when Solaris is used. --Jani --- [2001-01-22 06:05:34] [EMAIL PROTECTED] PHP compiled as Apache module. Look like crypt() starts from not random salt. In case of my Solaris 2.4, first crypt() call always generates string starting from "IH". In case of Solaris 2.6 it always starts from "C.". Looks like in every instantiation of new Apache process PHP starts crypt from the same salt value. In the same process next crypt() calls look like they generate random strings, though. But next process restarts with the same value. --- Full Bug description available at: http://bugs.php.net/?id=8834 -- 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 Bug #10171 Updated: calling function before it is defined only works in same file
ID: 10171 User Update by: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Documentation problem Description: calling function before it is defined only works in same file Thanks for the info from Andi and cynic. The reason this feature is so nice is because I have a wrapper that pulls in whatever Web page is being viewed. The wrapper needs to change its headers on the fly, depending on page contents. I wanted to use the functions as a signal of some sort -- the page content telling the wrapper, "send this header". I can't do this if I can't call functions in included files. So if includes and requires don't work out, I hope the gang comes up with some way for different bits of code to message each other. In any case, I've added a note to the documentation, so I think the documentation end of things is now fixed. I'll close this bug. Thanks! Previous Comments: --- [2001-04-05 05:03:25] [EMAIL PROTECTED] problem here is that include()s require()s are runtime thingies. I got bitten by this just yesterday: if you e. g. redeclare a function in a require()d file, the 'fatal error: function redeclaration...' does appear, but at runtime, not during compilation. Anyway, this is what Andi told me on the subject: The main reason [require() was changed to happen at run time rather than at compile time] was that it was supposed to improve performance and it didn't. It actually tended to slow things down. Removing this also allowed us to reduce the memory usage of PHP scripts (not as important). (...) It really sucked and we managed to clean up some code and internals due to taking it out. I wouldn't want to put it back in. So, this is by design. - docuprob --- [2001-04-04 19:05:28] [EMAIL PROTECTED] Define a function. Put a call to that function BEFORE it is defined. That works, as documented. Now put the function in an include()'d or require()'d file. Call the function before the include() or require(). It fails. Since the code is pre-compiled beforehand, shouldn't the function calls still work? If this is "as designed" it might be nice to place a caveat in the documentation that states "you can call a function before you define it ONLY if the function isn't buried in an include()." --- Full Bug description available at: http://bugs.php.net/?id=10171 -- 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] Request for new feature: $HTTP_SESSION_VARS whenregister_globals = on
This makes sense. The behaviour quoted below creates difficulties when writing portable scripts (not to depend on the value of register_globals). Rgds: -- Alex On Thu, 5 Apr 2001, Carsten Gehling wrote: One of the IMHO stranger behaviors in PHP is what happens to the $HTTP_SESSION_VARS array when changing register_globals from off to on. If register_globals is set to on, you cannot access $HTTP_SESSION_VARS any longer. Instead you can get the values through implicit created variables or through the $GLOBALS array. Now compare this to $HTTP_GET_VARS and $HTTP_POST_VARS. Both of these arrays are available regardless of what register_globals is set to. Shouldn't it be the same for $HTTP_SESSION_VARS ? - Carsten -- 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] PHP 4.0 Bug #8834 Updated: crypt() starts from not random salt
I too have seen this, but I assumed it you had to put a random salt key in. I picked the system mseconds and put that in a random seed to get a random salt key. I was also on Solaris 2.6. Simple work around if its not supposed to work that way. On 5 Apr 2001 18:57:45 -, [EMAIL PROTECTED] wrote: ID: 8834 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Strings related Assigned To: Comments: This is most likely a Solaris specific issue as I can't reproduce this on Linux. Can you please include the output of this command in both Solaris 2.4 and 2.6 (in php4): # grep RAND main/php_config.h It might be that in both of those system the seed generator found is srand() which isn't so good as srandom() is. But I also found (with google :) that srandom() might not be that good either (in Solaris) so that leaves us with a problem. One solution might be that we run php_srand() in RINIT instead of MINIT when Solaris is used. --Jani Previous Comments: --- [2001-01-22 06:05:34] [EMAIL PROTECTED] PHP compiled as Apache module. Look like crypt() starts from not random salt. In case of my Solaris 2.4, first crypt() call always generates string starting from "IH". In case of Solaris 2.6 it always starts from "C.". Looks like in every instantiation of new Apache process PHP starts crypt from the same salt value. In the same process next crypt() calls look like they generate random strings, though. But next process restarts with the same value. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8834edit=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 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 Bug #10193 Updated: Gargbage characters returned.
ID: 10193 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Description: Gargbage characters returned. my email is [EMAIL PROTECTED] Previous Comments: --- [2001-04-05 17:16:03] [EMAIL PROTECTED] About every 5 or 6 refreshes of several pages on the site, garbage characters are returned causing the page to display incorrectly. I cannot replicate for any particular characters but it is happening on a regular basis. I am using IIS 5. It is not reporting any errors but the characters are not correct. For instance a submit button may read 'input type=suEGOR' instead of 'input type=submit' --- Full Bug description available at: http://bugs.php.net/?id=10193 -- 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 Bug #10194: crypt() doesn't do md5
From: [EMAIL PROTECTED] Operating system: OpenBSD 2.7 PHP version: 4.0.4pl1 PHP Bug Type: *Encryption and hash functions Bug description: crypt() doesn't do md5 I have not tested with other crypts, but the constant CRYPT_MD5 is true. All crypted strings come out as DES. (this was a working site, salt begins with $1$, etc.) -- Edit Bug report at: http://bugs.php.net/?id=10194edit=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] Request for new feature: $HTTP_SESSION_VARS when register_globals = on
+1 -Chris -Original Message- From: Alexander Feldman [mailto:[EMAIL PROTECTED]] Sent: Thursday, 05 April, 2001 1-44 pM To: Carsten Gehling Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Request for new feature: $HTTP_SESSION_VARS when register_globals = on This makes sense. The behaviour quoted below creates difficulties when writing portable scripts (not to depend on the value of register_globals). Rgds: -- Alex On Thu, 5 Apr 2001, Carsten Gehling wrote: One of the IMHO stranger behaviors in PHP is what happens to the $HTTP_SESSION_VARS array when changing register_globals from off to on. If register_globals is set to on, you cannot access $HTTP_SESSION_VARS any longer. Instead you can get the values through implicit created variables or through the $GLOBALS array. Now compare this to $HTTP_GET_VARS and $HTTP_POST_VARS. Both of these arrays are available regardless of what register_globals is set to. Shouldn't it be the same for $HTTP_SESSION_VARS ? - Carsten -- 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] PHP 4.0 Bug #8834 Updated: crypt() starts from not random salt
ID: 8834 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: Strings related Description: crypt() starts from not random salt here you are: Solaris 2.4: # grep RAND main/php_config.h #define HAVE_LRAND48 1 #define HAVE_RAND_R 1 /* #undef HAVE_RANDOM */ #define HAVE_SRAND48 1 /* #undef HAVE_SRANDOM */ # uname -a SunOS helios 5.4 Generic_101945-60 sun4d sparc # Solaris 2.6 # grep RAND main/php_config.h #define HAVE_LRAND48 1 #define HAVE_RAND_R 1 #define HAVE_RANDOM 1 #define HAVE_SRAND48 1 #define HAVE_SRANDOM 1 # uname -a SunOS uranos 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-4 # unfortunately I'm not able to discuss the solution, although I can test the one provided :-)), thank you Previous Comments: --- [2001-04-05 15:14:41] [EMAIL PROTECTED] here you are: Solaris 2.4: # grep RAND main/php_config.h #define HAVE_LRAND48 1 #define HAVE_RAND_R 1 /* #undef HAVE_RANDOM */ #define HAVE_SRAND48 1 /* #undef HAVE_SRANDOM */ # uname -a SunOS helios 5.4 Generic_101945-60 sun4d sparc # Solaris 2.6 # grep RAND main/php_config.h #define HAVE_LRAND48 1 #define HAVE_RAND_R 1 #define HAVE_RANDOM 1 #define HAVE_SRAND48 1 #define HAVE_SRANDOM 1 # uname -a SunOS uranos 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-4 # unfortunately I'm not able to discuss the solution, although I can test the one provided :-)), thank you --- [2001-04-05 14:57:44] [EMAIL PROTECTED] This is most likely a Solaris specific issue as I can't reproduce this on Linux. Can you please include the output of this command in both Solaris 2.4 and 2.6 (in php4): # grep RAND main/php_config.h It might be that in both of those system the seed generator found is srand() which isn't so good as srandom() is. But I also found (with google :) that srandom() might not be that good either (in Solaris) so that leaves us with a problem. One solution might be that we run php_srand() in RINIT instead of MINIT when Solaris is used. --Jani --- [2001-01-22 06:05:34] [EMAIL PROTECTED] PHP compiled as Apache module. Look like crypt() starts from not random salt. In case of my Solaris 2.4, first crypt() call always generates string starting from "IH". In case of Solaris 2.6 it always starts from "C.". Looks like in every instantiation of new Apache process PHP starts crypt from the same salt value. In the same process next crypt() calls look like they generate random strings, though. But next process restarts with the same value. --- Full Bug description available at: http://bugs.php.net/?id=8834 -- 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 Bug #8895 Updated: xslt_process() documentation problem
ID: 8895
User Update by: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: Sablotron XSL
Description: xslt_process() documentation problem
This is ridiculous - this is the second time this bug has been closed by someone who
never bothered to read the report!
According to the documentation:
The xslt_process() takes a string containing the XSLT stylesheet as its first
argument, it takes a second string containing the XML data you want to transform and
then a third string containing the results of the transformation. xslt_process() will
return true on success and false on failure, to get the error number and error string
if an error occurs use the xslt_errno() and xslt_error() functions.
There is no conceivable way returning an untrappable fatal error can be seen as a
simple return false, particularly since the comment about errors suggests that your
script will continue executing if xslt_process() encounters an error. Currently,
there's no way to call xslt_errno() / xslt_error().
There are three options at this point: actually fixing the Sablotron extension or
changing the documentation to say something like "If the transform fails, PHP will
immediately terminate with a fatal error". Or you could just close it a 3rd time with
a bogus comment - I won't bother reopening it, as I don't use Sablotron regularly.
This still reproduces with 4.0.5-dev, built from a CVS checkout on 3/26.
Previous Comments:
---
[2001-04-05 14:16:06] [EMAIL PROTECTED]
this is the correct behavior, if the transformation fails so
will php.
---
[2001-02-14 10:53:39] [EMAIL PROTECTED]
Please try to read the bug report before closing it. xslt_process() does *NOT* return
false with some errors. Instead, it returns a PHP fatal error which cannot be trapped
using @.
---
[2001-02-14 06:19:21] [EMAIL PROTECTED]
not a bug. xslt_process() returns false on failure, you can supress errors using the
@ sign.
---
[2001-01-25 02:02:18] [EMAIL PROTECTED]
According to the documentation xslt_process() is supposed to return false and allow
you to check errors with xslt_errno() xslt_error().
I found several situations where a validation error in the XSL stylesheet would cause
it to instead fail with a fatal error:
PHP Fatal error: msgtype: error
in /var/www/stone2/index.php on line 18
(One example of an error would be a HTML tag with unquoted parameters (e.g. BORDER=0),
which is legal for numeric values in HTML but not XML)
Needless to say, this made debugging rather tricky as it never reached the error
display in my code:
if (xslt_process($XSL, $XML, $result)) {
echo $result;
} else {
echo 'PXSL transformation error: /P';
echo xslt_errno() . ': ' . xslt_error();
}
PHP config info:
PHP Version 4.0.4pl1
System Linux gigante 2.2.18pre21 #1 Sat Nov 18 18:47:15 EST 2000 i686
unknown
Build Date Jan 24 2001
Configure Command './configure' '--with-apxs' '--enable-shared'
'--with-bz2' '--with-java=/usr/local/jdk1.3' '--with-gettext'
'--with-mcrypt' '--with-zlib' '--with-openssl=/usr/local/ssl'
'--enable-magic-quotes' '--enable-calendar' '--with-curl'
'--with-mcrypt' '--with-dom=/usr/local/lib' '--enable-ftp'
'--enable-gd-imgstrttf' '--with-gd' '--with-jpeg-dir' '--with-ttf'
'--with-t1lib' '--with-imap-ssl' '--with-imap' '--with-ldap'
'--with-mysql' '--with-pdflib=/usr/local/lib' '--with-zlib-dir'
'--with-jpeg-dir' '--with-png-dir' '--with-tiff-dir' '--with-pgsql'
'--with-pspell' '--with-readline' '--with-sablot'
'--with-sablot-errors-descriptive' '--enable-trans-sid'
'--enable-shmop' '--enable-sockets' '--with-swf' '--enable-sysvsem'
'--enable-sysvshm' '--enable-inline-optimization'
'--enable-memory-limit'
---
Full Bug description available at: http://bugs.php.net/?id=8895
--
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 Bug #10192: sybase_query with sybase_fetch_row displays real data type incorrectly
From: [EMAIL PROTECTED] Operating system: Linux Mandrake (redhat) 7.0 PHP version: 4.0.3pl1 PHP Bug Type: Sybase (dblib) related Bug description: sybase_query with sybase_fetch_row displays real data type incorrectly Queries that produce incorrect data is random, but will consistently happen within a particular query. In one case, the last value of a fetched row (a real), in the last row was "1" in the database, but the returned array always displayed "0". In another case, a value (a real) in the middle of the returned array in the database was supposed to be "65000" but the fetched array contained "0". In both cases I copied the query from the code EXACTLY and ran it in isql and those results were correct. So the errors are occuring somewhere in php land. This error seems serious since no errors/messages are produced, but the data displayed is incorrect. Sybase's real data type is machine-dependent, and my database is on a Solaris system. But if isql on my linux php machine fetches data correctly, I would expect php to be able to do the same. Complied with: --with-apxs=/usr/sbin/apxs --with-sybase=/opt/sybase --without-mysql --with-layout=RedHat --enable-shared=max -- Edit Bug report at: http://bugs.php.net/?id=10192edit=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] Request for new feature: $HTTP_SESSION_VARS when register_globals = on
Yes, what you're saying definitely makes sense and I think it should be fixed. Andi At 09:20 PM 4/5/2001 +0200, Carsten Gehling wrote: One of the IMHO stranger behaviors in PHP is what happens to the $HTTP_SESSION_VARS array when changing register_globals from off to on. If register_globals is set to on, you cannot access $HTTP_SESSION_VARS any longer. Instead you can get the values through implicit created variables or through the $GLOBALS array. Now compare this to $HTTP_GET_VARS and $HTTP_POST_VARS. Both of these arrays are available regardless of what register_globals is set to. Shouldn't it be the same for $HTTP_SESSION_VARS ? - Carsten -- 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] PHP 4.0 Bug #8895 Updated: xslt_process() documentation problem
ID: 8895
Updated by: sterling
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Sablotron XSL
Assigned To: sterling
Comments:
The xslt_process() function *does* return false on failure.
However, if the error is serious enough, the php script
will exit out, as with any of the sablotron functions.
Furthermore, it never sends a fatal error if the
transformation fails, it sends an error of type E_ERROR for
critical sablotron errors transformations and an error of
type E_WARNING for warnings.
Previous Comments:
---
[2001-04-05 17:00:23] [EMAIL PROTECTED]
This is ridiculous - this is the second time this bug has been closed by someone who
never bothered to read the report!
According to the documentation:
The xslt_process() takes a string containing the XSLT stylesheet as its first
argument, it takes a second string containing the XML data you want to transform and
then a third string containing the results of the transformation. xslt_process() will
return true on success and false on failure, to get the error number and error string
if an error occurs use the xslt_errno() and xslt_error() functions.
There is no conceivable way returning an untrappable fatal error can be seen as a
simple return false, particularly since the comment about errors suggests that your
script will continue executing if xslt_process() encounters an error. Currently,
there's no way to call xslt_errno() / xslt_error().
There are three options at this point: actually fixing the Sablotron extension or
changing the documentation to say something like "If the transform fails, PHP will
immediately terminate with a fatal error". Or you could just close it a 3rd time with
a bogus comment - I won't bother reopening it, as I don't use Sablotron regularly.
This still reproduces with 4.0.5-dev, built from a CVS checkout on 3/26.
---
[2001-04-05 14:16:06] [EMAIL PROTECTED]
this is the correct behavior, if the transformation fails so
will php.
---
[2001-02-14 10:53:39] [EMAIL PROTECTED]
Please try to read the bug report before closing it. xslt_process() does *NOT* return
false with some errors. Instead, it returns a PHP fatal error which cannot be trapped
using @.
---
[2001-02-14 06:19:21] [EMAIL PROTECTED]
not a bug. xslt_process() returns false on failure, you can supress errors using the
@ sign.
---
[2001-01-25 02:02:18] [EMAIL PROTECTED]
According to the documentation xslt_process() is supposed to return false and allow
you to check errors with xslt_errno() xslt_error().
I found several situations where a validation error in the XSL stylesheet would cause
it to instead fail with a fatal error:
PHP Fatal error: msgtype: error
in /var/www/stone2/index.php on line 18
(One example of an error would be a HTML tag with unquoted parameters (e.g. BORDER=0),
which is legal for numeric values in HTML but not XML)
Needless to say, this made debugging rather tricky as it never reached the error
display in my code:
if (xslt_process($XSL, $XML, $result)) {
echo $result;
} else {
echo 'PXSL transformation error: /P';
echo xslt_errno() . ': ' . xslt_error();
}
PHP config info:
PHP Version 4.0.4pl1
System Linux gigante 2.2.18pre21 #1 Sat Nov 18 18:47:15 EST 2000 i686
unknown
Build Date Jan 24 2001
Configure Command './configure' '--with-apxs' '--enable-shared'
'--with-bz2' '--with-java=/usr/local/jdk1.3' '--with-gettext'
'--with-mcrypt' '--with-zlib' '--with-openssl=/usr/local/ssl'
'--enable-magic-quotes' '--enable-calendar' '--with-curl'
'--with-mcrypt' '--with-dom=/usr/local/lib' '--enable-ftp'
'--enable-gd-imgstrttf' '--with-gd' '--with-jpeg-dir' '--with-ttf'
'--with-t1lib' '--with-imap-ssl' '--with-imap' '--with-ldap'
'--with-mysql' '--with-pdflib=/usr/local/lib' '--with-zlib-dir'
'--with-jpeg-dir' '--with-png-dir' '--with-tiff-dir' '--with-pgsql'
'--with-pspell' '--with-readline' '--with-sablot'
'--with-sablot-errors-descriptive' '--enable-trans-sid'
'--enable-shmop' '--enable-sockets' '--with-swf' '--enable-sysvsem'
'--enable-sysvshm' '--enable-inline-optimization'
'--enable-memory-limit'
---
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
[PHP-DEV] Object Constructors in PHP
Don't ask why it is this way, but say we have these files:
::
inc1.php
::
?
class base {
function ForumStyle() {
echo ('hi');
}
}
?
::
inc2.php
::
?
class ForumStyle extends base {
var $temp;
}
?
::
inc3.php
::
?
class Outline_ForumStyle extends ForumStyle {
function Outline_ForumStyle () {
$this-ForumStyle();
}
}
?
::
test.php
::
?
include ('inc1.php');
include ('inc2.php');
include ('inc3.php');
$i = new Outline_ForumStyle();
It runs fine printing 'hi' (though not with APC, but fine with Zend Cache).
BUT, What _should_ happen?
BTW: For the APC list, this is a test case of bug #3. Use the apc_gui to
look at inc3.php
Sincerely,
Steven Roussey
Network54.com
http://network54.com/?pp=e
--
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] CVS Account Request
Full name: Boris Arsov Email: [EMAIL PROTECTED] ID: borisphp Purpose: Learning -- 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 Bug #9369 Updated: Bug in foreach, reference (See Bug ID#9365, too)
ID: 9369
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Description: Bug in foreach, reference (See Bug ID#9365, too)
I've tested against
- PHP4.0.5RC1 Windows/Apache SAPI
- PHP4.0.5RC6 Linux/Apache SAPI
It's still there.
I think this bug is better to be fixed soon, even if this is a programmer's error. For
example, if user change HTML form values from array to sclar and forgot to change PHP
code, programmers are crueless what's wrong. If PHP could issue warning, it would be
easy to find problem.
Please let me know if you don't have this problem.
FYI:
Very simpile code like follows PHP works as it should be (Warning message is
displyed), but not for longer code. ('server not found or dns error' or empty page.
Try code that I've submitted. The later one is self contained single file.)
?php
$str = 'A';
// This works (raise warning message)
foreach ($str as $v = $k) {
}
?
Previous Comments:
---
[2001-03-16 22:08:35] [EMAIL PROTECTED]
After I upgraded my test machine's glibc and gcc, I didn't check if this bug is happen
on my machine. Unfortunately it still exists. (Upgrading glibc fixed malformed man
pages when EUC-JP is used, though)
I wrote a new test code for developers so that you can easily verify this bug. (Single
php file with HTML form to play with this errata)
Note: First of all, programmers should NOT write this kind of code. i.e. Using scalar
where array is expected, this is error anyway.
Try test case "foreach and value" and "foreach and reference". PHP does not complain
illegal use of variable at all, but empty outputs.
This PHP behavior is not acceptable for many users I think. Since if programmer write
PHP code, that does this kind of illegal use of variables, can be very hard to find.
I also interested in why PHP behave differently when ASCII is used for scalar and when
EUC-JP (Multi-byte Charset) is used for scalar.
source code ===
html
head
titleForeach and Reference Test/title
meta http-equiv="Content-Type" content="text/html; charset=EUC-JP"
/head
body bgcolor="#FF"
h1Foreach and Reference Bug Test Page/h1
h3Test Function: ?php isset($HTTP_POST_VARS['action']) ?
print($HTTP_POST_VARS['action']) : print('Function is not set'); ?/h3
h3Test Param: ?php isset($HTTP_POST_VARS['test_mode']) ?
print($HTTP_POST_VARS['test_mode']) : print('Mode is not set'); ?/h3
form name="form1" method="post"
input type="submit" name="Submit" value="while and value"
input type="hidden" name="action" value="while_and_value"
input type="radio" name="test_mode" value="ascii" checked
ASCII Text Scalar
input type="radio" name="test_mode" value="euc_jp"
EUC-JP Text Scalar
/form
form name="form2" method="post"
input type="submit" name="Submit2" value="while and reference"
input type="hidden" name="action" value="while_and_reference"
input type="radio" name="test_mode" value="ascii" checked
ASCII Text Scalar
input type="radio" name="test_mode" value="euc_jp"
EUC-JP Text Scalar
/form
h3@/h3
form name="form3" method="post"
input type="submit" name="Submit3" value="foreach and value"
input type="hidden" name="action" value="foreach_and_value"
input type="radio" name="test_mode" value="ascii" checked
ASCII Text Scalar
input type="radio" name="test_mode" value="euc_jp"
EUC-JP Text Scalar
/form
form name="form4" method="post"
input type="submit" name="Submit22" value="foreach and reference"
input type="hidden" name="action" value="foreach_and_reference"
input type="radio" name="test_mode" value="ascii" checked
ASCII Text Scalar
input type="radio" name="test_mode" value="euc_jp"
EUC-JP Text Scalar
/form
?php
// NOTE: error report level is E_ALL
$ascii = 'abcdefghijklmn'; // plain ascii
$euc_jp = ' ¢¤¦¨©«¯±'; // multi-byte EUC char code
function while_and_value($msg) {
while (list($k,$v) = each($msg[1])) {
print($v);
}
while (list($k,$v) = each($msg[0])) {
print($v);
}
}
function while_and_reference($msg) {
while (list($k,$v) = each($msg[1])) {
print($v);
}
while (list($k,$v) = each($msg[0])) {
print($v);
}
}
function foreach_and_value($msg) {
foreach ($msg[1] as $v) {
print($v);
}
foreach ($msg[0] as $v) {
print($v);
}
}
function foreach_and_reference($msg) {
foreach ($msg[1] as $v) {
print($v);
}
foreach ($msg[0] as $v) {
print($v);
}
}
// Call function specified with $action with a paramter specified with $test_mode
if (isset($HTTP_POST_VARS['action'])) {
$test_mode = $HTTP_POST_VARS['test_mode']; // ascii or euc_jp
$action = $HTTP_POST_VARS['action']; // One of 4 function
$action($$test_mode);
}
?
/body
/html
---
[2001-02-21 08:09:12]
Re: [PHP-DEV] PHP 4.0 Bug #10192: sybase_query with sybase_fetch_row displays real data type incorrectly
Try this patch, which also adds support for FLT8. Also, this applies to
both PHP3 and PHP4, and the sybase_ct functions don't have this problem.
--- sybase.c.orig Mon Feb 7 16:54:51 2000
+++ sybase.cMon Apr 3 12:12:00 2000
@@ -635,9 +640,13 @@
result-type = IS_STRING;
break;
}
- /*case SYBFLT8:*/
+ case SYBFLT8:
+ result-value.dval = *(DBFLT8
*)dbdata(sybase_ptr-link,offset);
+ result-type = IS_DOUBLE;
+ break;
+
case SYBREAL: {
- result-value.dval = (double) floatcol(offset);
+ result-value.dval = (double)(*(DBREAL
*)dbdata(sybase_ptr-link,offset));
result-type = IS_DOUBLE;
break;
}
At 08:06 PM 05/04/01 +, [EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED]
Operating system: Linux Mandrake (redhat) 7.0
PHP version: 4.0.3pl1
PHP Bug Type: Sybase (dblib) related
Bug description: sybase_query with sybase_fetch_row displays real data
type incorrectly
Queries that produce incorrect data is random, but will consistently
happen within a particular query. In one case, the last value of a
fetched row (a real), in the last row was "1" in the database, but the
returned array always displayed "0". In another case, a value (a real) in
the middle of the returned array in the database was supposed to be
"65000" but the fetched array contained "0". In both cases I copied the
query from the code EXACTLY and ran it in isql and those results were
correct. So the errors are occuring somewhere in php land. This error
seems serious since no errors/messages are produced, but the data
displayed is incorrect. Sybase's real data type is machine-dependent, and
my database is on a Solaris system. But if isql on my linux php machine
fetches data correctly, I would expect php to be able to do the same.
Complied with:
--with-apxs=/usr/sbin/apxs
--with-sybase=/opt/sybase
--without-mysql
--with-layout=RedHat
--enable-shared=max
--
Edit Bug report at: http://bugs.php.net/?id=10192edit=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 Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #8895 Updated: xslt_process() documentation problem
On 5 Apr 2001 17:05:34 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ID: 8895 Updated by: sterling Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Sablotron XSL Assigned To: sterling Comments: The xslt_process() function *does* return false on failure. However, if the error is serious enough, the php script will exit out, as with any of the sablotron functions. Furthermore, it never sends a fatal error if the transformation fails, it sends an error of type E_ERROR for critical sablotron errors transformations and an error of type E_WARNING for warnings. This sounds like a question of semantics - I consider anything which will cause PHP to halt execution with the message "Fatal Error" as a fatal error, even if the sablotron extension is doing a RETURN_FALSE internally. Since there's no possible way for a PHP developer to trap such an error, it sounds like the documentation should be updated to reflect the way xslt_process() actually behaves. -- 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 Bug #10196: pspell functions no longer work
From: [EMAIL PROTECTED] Operating system: FreeBSD v4.2 PHP version: 4.0.4pl1 PHP Bug Type: Pspell related Bug description: pspell functions no longer work The Pspell functions no longer work after upgrading to pspell 0.12 and aspell 0.33. I know you have added the pspell author's recommendation to interface with the old functions but that didn't seem to help at all. Thanks. -- Edit Bug report at: http://bugs.php.net/?id=10196edit=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] PHP 4.0 Bug #10196 Updated: pspell functions no longer work
ID: 10196 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: Pspell related Description: pspell functions no longer work pspell_new_config() at least is not returning a link value. Previous Comments: --- [2001-04-05 22:12:34] [EMAIL PROTECTED] The Pspell functions no longer work after upgrading to pspell 0.12 and aspell 0.33. I know you have added the pspell author's recommendation to interface with the old functions but that didn't seem to help at all. Thanks. --- Full Bug description available at: http://bugs.php.net/?id=10196 -- 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] PEAR_INSTALLDIR breakage
Revision 1.228 of configure.in breaks the expansion of the
PEAR_INSTALLDIR variable. I don't know why the $'s were escaped in
revision 1.228, but the following patch brings back what I think is
the intended behavior.
Is there a reason the $'s were escape, or can I commit my fix?
Index: configure.in
===
RCS file: /repository/php4/configure.in,v
retrieving revision 1.229
diff -u -r1.229 configure.in
--- configure.in2001/04/04 20:52:43 1.229
+++ configure.in2001/04/06 02:51:23
@@ -717,9 +717,9 @@
PEAR_INSTALLDIR="$prefix/lib/php"
fi
-EXTENSION_DIR="\${PEAR_INSTALLDIR}/extensions/$PART1-$PART2-$ZEND_MODULE_API_NO"
+EXTENSION_DIR="${PEAR_INSTALLDIR}/extensions/$PART1-$PART2-$ZEND_MODULE_API_NO"
-INCLUDE_PATH=".:\${PEAR_INSTALLDIR}"
+INCLUDE_PATH=".:${PEAR_INSTALLDIR}"
PHP_BUILD_RPATH
--
Jon Parise ([EMAIL PROTECTED]) . Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/ : Computer Science House Member
--
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: arg_separator (MFH) + possible patch to handle old arg_separatorissue..
On Thu, 5 Apr 2001, Andi Gutmans wrote:
At 10:22 AM 4/5/2001 +0200, Sascha Schumann wrote:
Am I the only one who thinks that breaking installations
which use a different arg_separator is odd? Now all those
working installations have to be manually modified just to
append ".output".
Considering the ambiguity I think it is the right thing to do. The default
behavior will be backwards compatible and we can have a big caps news entry
about it (for people who changed arg_separator). We could also keep
arg_separator as an INI parameter in 4.0.5 and raise an error with a
message on how to fix it (changing arg_separator to arg_separator.output).
I did MFH for those changes into PHP_4_0_5 branch.
But I didn't want to commit this change into it yet before hearing
whether it's the proper way to handle the old arg_separator problem:
(also included as attachment..)
Index: main.c
===
RCS file: /repository/php4/main/main.c,v
retrieving revision 1.356.2.2
diff -u -u -r1.356.2.2 main.c
--- main.c 2001/04/06 02:09:43 1.356.2.2
+++ main.c 2001/04/06 03:14:44
@@ -139,6 +139,18 @@
}
+static PHP_INI_MH(OnUpdateDeprecated)
+{
+ PLS_FETCH();
+
+ PG(arg_separator.output) = new_value;
+
+ if (stage==PHP_INI_STAGE_RUNTIME) {
+ php_error(E_WARNING, "The arg_separator directive is deprecated. Use
+arg_separator.output instead");
+ }
+ return SUCCESS;
+}
+
static PHP_INI_MH(OnUpdateTimeout)
{
ELS_FETCH();
@@ -211,6 +223,7 @@
STD_PHP_INI_ENTRY("arg_separator.output", "",PHP_INI_ALL,
OnUpdateStringUnempty,arg_separator.output,php_core_globals,
core_globals)
STD_PHP_INI_ENTRY("arg_separator.input","",
PHP_INI_SYSTEM|PHP_INI_PERDIR, OnUpdateStringUnempty, arg_separator.input,
php_core_globals, core_globals)
+ PHP_INI_ENTRY("arg_separator", "",PHP_INI_ALL,
+ OnUpdateDeprecated)
STD_PHP_INI_ENTRY("auto_append_file", NULL, PHP_INI_ALL,
OnUpdateString, auto_append_file,php_core_globals,
core_globals)
STD_PHP_INI_ENTRY("auto_prepend_file", NULL, PHP_INI_ALL,
OnUpdateString, auto_prepend_file, php_core_globals,
core_globals)
Index: main.c
===
RCS file: /repository/php4/main/main.c,v
retrieving revision 1.356.2.2
diff -u -u -r1.356.2.2 main.c
--- main.c 2001/04/06 02:09:43 1.356.2.2
+++ main.c 2001/04/06 03:19:48
@@ -139,6 +139,18 @@
}
+static PHP_INI_MH(OnUpdateDeprecated)
+{
+ PLS_FETCH();
+
+ PG(arg_separator.output) = new_value;
+
+ if (stage==PHP_INI_STAGE_RUNTIME) {
+ php_error(E_WARNING, "The arg_separator directive is deprecated. Use
+arg_separator.output instead");
+ }
+ return SUCCESS;
+}
+
static PHP_INI_MH(OnUpdateTimeout)
{
ELS_FETCH();
@@ -211,6 +223,7 @@
STD_PHP_INI_ENTRY("arg_separator.output", "",PHP_INI_ALL,
OnUpdateStringUnempty, arg_separator.output, php_core_globals,
core_globals)
STD_PHP_INI_ENTRY("arg_separator.input","",
PHP_INI_SYSTEM|PHP_INI_PERDIR, OnUpdateStringUnempty, arg_separator.input,
php_core_globals, core_globals)
+ PHP_INI_ENTRY("arg_separator", "",
+PHP_INI_ALL,OnUpdateDeprecated)
STD_PHP_INI_ENTRY("auto_append_file", NULL, PHP_INI_ALL,
OnUpdateString, auto_append_file,
php_core_globals, core_globals)
STD_PHP_INI_ENTRY("auto_prepend_file", NULL, PHP_INI_ALL,
OnUpdateString, auto_prepend_file,
php_core_globals, core_globals)
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #8895 Updated: xslt_process() documentationproblem
On Thu, 5 Apr 2001, Chris Adams wrote: On 5 Apr 2001 17:05:34 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ID: 8895 Updated by: sterling Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Sablotron XSL Assigned To: sterling Comments: The xslt_process() function *does* return false on failure. However, if the error is serious enough, the php script will exit out, as with any of the sablotron functions. Furthermore, it never sends a fatal error if the transformation fails, it sends an error of type E_ERROR for critical sablotron errors transformations and an error of type E_WARNING for warnings. This sounds like a question of semantics - I consider anything which will cause PHP to halt execution with the message "Fatal Error" as a fatal error, even if the sablotron extension is doing a RETURN_FALSE internally. Since there's no possible way for a PHP developer to trap such an error, it sounds like the documentation should be updated to reflect the way xslt_process() actually behaves. In some cases you *can* trap the error, that's why its documented as so. Other cases its not possible (E_WARNING or no error thrown, such as inability to allocate memory), its the same way with many other functions in php. -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] PHP 4.0 Bug #8895 Updated: xslt_process() documentation problem
On Thu, Apr 05, 2001 at 10:29:03PM -0400, Sterling Hughes wrote: On Thu, 5 Apr 2001, Chris Adams wrote: On 5 Apr 2001 17:05:34 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ID: 8895 The xslt_process() function *does* return false on failure. However, if the error is serious enough, the php script will exit out, as with any of the sablotron functions. Furthermore, it never sends a fatal error if the transformation fails, it sends an error of type E_ERROR for critical sablotron errors transformations and an error of type E_WARNING for warnings. This sounds like a question of semantics - I consider anything which will cause PHP to halt execution with the message "Fatal Error" as a fatal error, even if the sablotron extension is doing a RETURN_FALSE internally. Since there's no possible way for a PHP developer to trap such an error, it sounds like the documentation should be updated to reflect the way xslt_process() actually behaves. In some cases you *can* trap the error, that's why its documented as so. Other cases its not possible (E_WARNING or no error thrown, such as inability to allocate memory), its the same way with many other functions in php. True - I just think this should be reflected more in the documentation (even if it is just "really nasty errors can't be trapped"), particularly in the case of functions like this which could die on user-provided data. Similarly, I'm guessing that Sablotron doesn't provide more debugging information but is there any way it could be a little more informative? It's a little frustrating to get that sort of error with 30K of complex XSL. Chris PGP signature
Re: [PHP-DEV] PHP 4.0 Bug #8895 Updated: xslt_process() documentationproblem
On Thu, 5 Apr 2001, Chris Adams wrote:
On Thu, Apr 05, 2001 at 10:29:03PM -0400, Sterling Hughes wrote:
On Thu, 5 Apr 2001, Chris Adams wrote:
On 5 Apr 2001 17:05:34 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
ID: 8895
The xslt_process() function *does* return false on failure.
However, if the error is serious enough, the php script
will exit out, as with any of the sablotron functions.
Furthermore, it never sends a fatal error if the
transformation fails, it sends an error of type E_ERROR for
critical sablotron errors transformations and an error of
type E_WARNING for warnings.
This sounds like a question of semantics - I consider anything which will cause
PHP to halt execution with the message "Fatal Error" as a fatal error, even if
the sablotron extension is doing a RETURN_FALSE internally. Since there's no
possible way for a PHP developer to trap such an error, it sounds like the
documentation should be updated to reflect the way xslt_process() actually
behaves.
In some cases you *can* trap the error, that's why its documented as so.
Other cases its not possible (E_WARNING or no error thrown, such as
inability to allocate memory), its the same way with many other functions
in php.
True - I just think this should be reflected more in the documentation (even if
it is just "really nasty errors can't be trapped"), particularly in the case of
functions like this which could die on user-provided data. Similarly, I'm
guessing that Sablotron doesn't provide more debugging information but is there
any way it could be a little more informative? It's a little frustrating to get
that sort of error with 30K of complex XSL.
You can use the xslt_set_error_handler() function...
?php
function errhandler()
{
var_dump(func_get_args());
}
xslt_set_error_handler("errhandler");
// do your thing
?
Or if you have an xslt processor allocated (with xslt_create()), simply
go:
xslt_set_error_handler($parser, "errhandler");
Good luck,
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] PHP 4.0 Bug #10195 Updated: https takes forever and a day to return when php is loaded in Apache
ID: 10195 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: OpenSSL related Description: https takes forever and a day to return when php is loaded in Apache Latest information. If I remove with-curl out from the configuration and rebuild PHP the problem no longer appears. I need the curl functionality to use https within the PHP script to another secure web server. Previous Comments: --- [2001-04-05 21:07:52] [EMAIL PROTECTED] I am running Apache 3.1.19 with mod_ssl-2.8.2-1.3.19 and OpenSSl-0.9.6 for SSL functionality. Using https from my Internet Explorer 5.0 browser causes the requested web page to be returned after a very long wait, .eg more than 20 minutes maybe longer. Subsequent retrieval takes as long too. If I have PHP disabled by removing the LoadModule and AddModule directive https works immediately however when I reinstate the PHP modules I would experience the problem again. Other scenario :- 1. retrieved a https page with my browser without PHP(response received immediately) 2. modify httpd.conf to enable PHP 3. restarts Apache 4. starts a *NEW* browser to retrieve https(waits very long) 5. using the same browser session in step 1 to retrieve again using https(response received immediately) Also noticed in the Apache errors_log file the following error :- [FriApr 6 11:46:302001] [notice]child pid 2654 exitsignal Segmentationfault (11) [FriApr 6 11:46:362001] [notice]child pid 2668 exitsignal Segmentationfault (11) [FriApr 6 11:46:362001] [notice]child pid 2667 exitsignal Segmentationfault (11) This is how I configure PHP :- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-config-file-path=/etc/php --with-mysql=/usr --with-java=/usr/java/jdk1.3 --with-ldap --with-imap --with-curl --with-gd --enable-versioning --- Full Bug description available at: http://bugs.php.net/?id=10195 -- 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] Apache 2
Sweet to see Apache 2 support availabe (--with-apxs2). Got it up and running under 2.0.16. What's the timeframe look like for this? There's really_silly, includes... Anything I can do to help? August -- 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]
