[PHP-DEV] Re: Bug #20936 Patch for use of public keys
Hi there, This is the patch for http://bugs.php.net/bug.php?id=20936 The file mentioned in the bug report is no longer available. I have very slightly changed the documentation also. The patch enables reading of public keys with the function openssl_pkey_get_public(). The following piece of code would fail before this patch was applied: ?php $key_string = __EOF__ -BEGIN PUBLIC KEY- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2ksziC2OJin7FhQZSWwC wJwYA43Iomrhm9Fw7+JOCwjnDGTu+kdsEVNBitzB3qrKjkMlqqTSaacuwc7EwRDe FKU0VaGHW8E1S+64juw56LIXEP/0I/r16O/feSd05mlOdNCfsNaZEXRiNQkfySDR loui+699FuXUGUyfIYBVVUmEpTWaH3+vKOmqM9H3ccndAgGC4PVVEGyDfnLMV+l2 uyc9SMAB+OH9qj9cQqI8rqYHTBB5KxjHqHfskvA9bQZEvGlwfz0+fKU/joMqiUie RV8YzKuh6G/zo5UFLgNXuYAGRt90zD+Fer9ivNJAx1yPvCp6OAvdCXMmEtgVJr1V TQIDAQAB -END PUBLIC KEY- __EOF__; $public_key = openssl_pkey_get_public( $key_string ); if ( !$public_key ) echo 'Error: ' . openssl_error_string() . \n; ? Result: Error: error:0906D06C:PEM routines:PEM_read_bio:no start line This is due to the fact that the php_openssl_evp_from_zval() function was only able to deal with certificates. Perhaps this was done on purpose, if so, could anyone explain? Applying the patch will make the above code work and also enable the resulting key resource to be used in e.g. the openssl_public_encrypt() function. Also a check was added to the php_openssl_evp_from_zval() which checks whether a key resource contains a private key if requested (because now it is possible that the key resource only contains a public key). For this a new function was introduced: static int php_openssl_is_private_key(EVP_PKEY* pkey TSRMLS_DC); TODO: perhaps a nicer solution would be to introduce another resource type: 'OpenSSL public key'? Please let me know what you think, Kind regards, Jeroen Derks -- drs. Jeroen Derks, CISSP, SCJP http://www.jeroenderks.com/ [EMAIL PROTECTED]http://www.derks.it/ Derks.IT gsm. +31 (0) 6 5577 8224 Postbus 56791 fax. +31 (0) 84 870 6519 1040 AT Amsterdam tel. +31 (0) 20 777 5488 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Select-List
I suppose you mean a multiple select-list: by adding [] to the name of the field, you get an array in PHP that has the selected items. SELECT NAME=name[] MULIPLE gives you an array $name[] -- Jeroen DragosB wrote: How can I check how many options has been selected from a select list? I tried in many ways, but it returns the last option selected. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #14623 Updated: get_meta_tags only looks in begin of file
ID: 14623 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Strings related Operating System: linux PHP Version: 4.0.6 Old Assigned To: elixer Assigned To: New Comment: ? $s = ... repeat this for about 110 lines of 80 'x'-es ; ? !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN html head titleFailing get_meta_tags/title META NAME=subject CONTENT=mySubject META NAME=keywords CONTENT=myKeywords link rel=stylesheet href=mysheet.css /head body GET_META_TAGS: ? print_r( get_meta_tags( $HTTP_SERVER_VARS[PATH_TRANSLATED])); ? /body /html Previous Comments: [2001-12-20 19:34:44] [EMAIL PROTECTED] Can you please provide me with a small example of a file that get_meta_tags is failing on? The only time I am seeing this fail is if the text /head appears in the working code that you mention. Sean [2001-12-20 10:59:01] [EMAIL PROTECTED] get_meta_tags() seems to look only in the beginning of a file, meaning that e.g. if there is a lot of PHP code before the HTML header it will return nothing ... Tested using get_meta_tags() on local files with about 9000 characters of PHP code before HTML HEADER. Might be by design (speed), but then a warning is needed in doc: when adding working code, things (get_meta_tags()) stop working ... Workaround: if possible move code after header or if not include a file :( Edit this bug report at http://bugs.php.net/?id=14623edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14623 Updated: get_meta_tags only looks in begin of file
ID: 14623 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Strings related Operating System: linux PHP Version: 4.0.6 Old Assigned To: elixer Assigned To: New Comment: The way I use it is quite different: When a file is parsed it is 'wrapped': a prepended wrapper opens the file and layouts it. Based on the meta tags a layout is choosen, menus added, header defined, etc. This way the content exists out of plain HTML files that are build into the vieuwed pages when parsed. (That can differ for showing, printing, spiders, ... all with the same content - that is easy to maintain even by dummies :).) Jeroen. Previous Comments: [2001-12-21 05:31:20] [EMAIL PROTECTED] Just a note... why would you want to do get_meta_tags on a non parsed file? I think it's makes way more sense to use g_m_t on a parsed file. Derick [2001-12-21 05:29:12] [EMAIL PROTECTED] ? $s = ... repeat this for about 110 lines of 80 'x'-es ; ? !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN html head titleFailing get_meta_tags/title META NAME=subject CONTENT=mySubject META NAME=keywords CONTENT=myKeywords link rel=stylesheet href=mysheet.css /head body GET_META_TAGS: ? print_r( get_meta_tags( $HTTP_SERVER_VARS[PATH_TRANSLATED])); ? /body /html [2001-12-20 19:34:44] [EMAIL PROTECTED] Can you please provide me with a small example of a file that get_meta_tags is failing on? The only time I am seeing this fail is if the text /head appears in the working code that you mention. Sean [2001-12-20 10:59:01] [EMAIL PROTECTED] get_meta_tags() seems to look only in the beginning of a file, meaning that e.g. if there is a lot of PHP code before the HTML header it will return nothing ... Tested using get_meta_tags() on local files with about 9000 characters of PHP code before HTML HEADER. Might be by design (speed), but then a warning is needed in doc: when adding working code, things (get_meta_tags()) stop working ... Workaround: if possible move code after header or if not include a file :( Edit this bug report at http://bugs.php.net/?id=14623edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14623: get_meta_tags only looks in begin of file
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.0.6 PHP Bug Type: Strings related Bug description: get_meta_tags only looks in begin of file get_meta_tags() seems to look only in the beginning of a file, meaning that e.g. if there is a lot of PHP code before the HTML header it will return nothing ... Tested using get_meta_tags() on local files with about 9000 characters of PHP code before HTML HEADER. Might be by design (speed), but then a warning is needed in doc: when adding working code, things (get_meta_tags()) stop working ... Workaround: if possible move code after header or if not include a file :( -- Edit bug report at: http://bugs.php.net/?id=14623edit=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: php4 /ext/standard math.c
derick Sun Dec 16 05:59:20 2001 EDT
Modified files:
/php4/ext/standard math.c
Log:
- Fix for bug #14544, bogus warning in pow()
Excuse me for disturbing, but it's actually wrong now. You cannot take the
logarithm of zero. As a consequence, in exponential ways of doing pow()
(i.e. with floating-point exponent) you MUST have a positive (implying
non-zero) base.
However, with a positive exponent, it is possible to determine the limit
base-0 of e^(log(base) * exp), which equals zero. You can argue wether or
not pow() should yield zero in this case, but as people expect pow(x,0.5) to
behave like sqrt(x), I agree it'd be better to yield zero.
In concreto:
Up until revision 1.66:
pow(x, y) [x0] = warning about nonpositive exponent
pow(0, y) [y=0] = warning about nonpositive exponent
pow(0, y) [y0] = warning
Revision 1.67:
pow(x, y) [x0] = warning about nonpositive exponent
pow(0, y) [y=0] = INF/NAN without warning
pow(0, y) [y0] = 0.0 (because exp(NEG_INF) returns 0.0)
I suggest:
pow(x, y) [x0] = warning about negative exponent
pow(0, y) [y=0] = different warning (pow(0, y) is undefined)
pow(0, y) [y0] = 0.0
[begin pseudo-diff]
+ if (Z_DVAL_PP(zbase) == 0.0) {
+ if (Z_DVAL_PP(zexp) 0) {
+RETURN_DOUBLE(0.0);
+ } else {
+ warning
+ }
+ }
if (Z_DVAL_PP(zbase) 0.0) { /* can remain like it is now after all */
:s/nonpostive/negative
[end pseudo-diff]
As for the bug, it is wrong to think that abs always yields a positive
value. abs returns a nonnegative value. So the warning DID correspond to the
case, this issue was that in this particular case it is possible to return a
decent result, even though base is nonpositive and exponent is broken
(=floating point).
#- I think I do not need to tell who screwed this up
Why are you so hatefull?
Regards,
--Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] bzcompress() bugfix
Hi,
I suggest MFH'ing the test for bz2. The problem is that size isn't
initialized at the time when it's passed to buff-compress.
I attached a patch to HEAD, for the PHP_4_0_7 branch I don't have a
patch yet, as I don't have more time currently to test it etc, but it
should be straight forward to adapt it to PHP_4_0_7.
I tested this patch. It makes the test work, and a test on a big file too.
The original intention was and is to not use buff(de)compress but those
stream functions in bzlib, in order to just (de)compress one time, in
stead of retrying all the time, but I didn't yet finish that.
--Jeroen
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://jeroen.A-Eskwadraat.nl
Index: bz2.c
===
RCS file: /repository/php4/ext/bz2/bz2.c,v
retrieving revision 1.29
diff -u -r1.29 bz2.c
--- bz2.c 1 Nov 2001 09:45:25 - 1.29
+++ bz2.c 13 Nov 2001 10:07:16 -
@@ -298,7 +298,8 @@
* of data + 600 which is the largest size the results of the compression
* could possibly be, at least that's what the libbz2 docs say (thanks to
* [EMAIL PROTECTED] for pointing this out). */
- dest = emalloc(Z_STRLEN_PP(source) + (0.01 * Z_STRLEN_PP(source)) + 601);
+ size = Z_STRLEN_PP(source) + (0.01 * Z_STRLEN_PP(source)) + 601;
+ dest = emalloc(size);
/* Handle the optional arguments */
if (ZEND_NUM_ARGS() 1) {
@@ -318,8 +319,9 @@
RETURN_FALSE;
}
- /* size down... */
- dest = erealloc(dest, size);
+ /* size down... and NUL-terminate */
+ dest = erealloc(dest, size+1);
+ dest[size] = 0;
RETURN_STRINGL(dest, size, 0);
}
/* }}} */
--
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: pow() showing odd long/float boundary case characteristics
Rasmus Lerdorf [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
The pow() regression test is failing due to this strange characteristic:
(...)
}
ie. pow(2147483647,1) returns a float where one would expect it to return
an int. Off by one error somewhere?
I'm quite certain (but not 100% certain of course) this is not the case. The
issue here is that in order to check wether the result is small enough to
fit into a float, I did a exp(log(base) * exp) (line 478), and check that
against long_max/min. Because of fp characteristics, this will give a false
alarm near the boundary: the check says it won't fit into int, but actually,
it does.
I could modify it to run the integer algorithm anyway, and check there for
overflows. Then no false alarms. Because the algorithm is very fast,
performance is not the issue.
Or just leave the code as it is, since the test nearly only exists of rare
boundary cases, it's not realistic. But agreed: it'd be better if always int
is returned when possible.
Same thing happens on the negative boundary.
Here neither is a off-by-one issue, though the code could have a bit more
comments. On entering this loop:
while (lexp 0) {
if (lexp 1) /* odd */
Z_LVAL_P(return_value) *= lbase;
lexp = 1;
lbase *= lbase;
}
lbase will be negative if it was originally, and if the result is negative,
lexp will be odd of course. So already in the first iteration return_value
will be negative, and that won't change anymore because lbase is squared,
and thus there will be taken full advantage of the larger negative range.
If you found a flaw/bug in the code, please mail me.
--Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Compile troubles, impossible to create .so extensions with current cvs?
FYI, I use ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18) on one machine, and ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) on the other. Downgrading to 1.3.3 did not solve the problem: ltmain.sh (GNU libtool) 1.3.3 (1.385.2.181 1999/07/02 15:49:11) I'm trying further... --Jeroen - Original Message - From: Jani Taskinen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, November 09, 2001 1:14 PM Subject: Re: [PHP-QA] Compile troubles, impossible to create .so extensions with current cvs? I think it's the libtool 1.4(.x) again that is breaking. Or we're doing something weird. Sascha might know? I noticed this myself sometime ago but I forgot about it.. --Jani On Fri, 9 Nov 2001 [EMAIL PROTECTED] wrote: Hi, First, I'm not well into compiling PHP in specific ways, so consider these semi-newbie questions. I hope someone has an idea about what could be going on, if so, please drop me a line. My system is Linux Debian unstable, everything relevant is up-to-date. My compile-line is: ./configure --disable-static --with-mysql=shared * Result on 406 dist: works fine, mysql.so appears in modules dir * Any recent snapshot: mysql.a and mysql.la appear in modules, but no .so * Latest cvs after ./buildconf: same result * getting back to 406 by means of CVS, ./buildconf fails: cvs up -r PHP_4_0_6 ./cvsclean make clean make distclean [jeroen@richard]~/php/php4 ./buildconf buildconf: checking installation... buildconf: autoconf version 2.52 (ok) buildconf: automake version 1.5 (ok) buildconf: libtool version 1.4 (ok) rebuilding Makefile templates rebuilding configure ./aclocal.m4:814: error: m4_defn: undefined macro: _m4_divert_diversion ./aclocal.m4:360: PHP_SUBST is expanded from... ./aclocal.m4:814: the top level rebuilding main/php_config.h.in ./aclocal.m4:814: error: m4_defn: undefined macro: _m4_divert_diversion ./aclocal.m4:360: PHP_SUBST is expanded from... ./aclocal.m4:814: the top level autoconf: tracing failed Thanks a lot Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13977 Updated: Sometimes php crashes when executing a script everytime at the same point.
ID: 13977
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: Windows 2000 SP2
PHP Version: 4.0.6
New Comment:
Derick wrote:
Please include the shortest possible script (preferrably link to it) that crashes
PHP.
Is this the shortest?? Try to weed out lines until it doesn't crash anymore, because
your script is a bit too long to check, and it's not self-containing either, it won't
run because of parse errors and missing includes.
YOu say it's because of DB access, try to do the specific queries only, and nothing
else.
Previous Comments:
[2001-11-09 07:02:42] [EMAIL PROTECTED]
Hi all,
the problem is, that the script not allways crashes. It just crashes on my home pc
with amd-cpu. I also put the script online (Linuxbox, Kernel 2.2.16, mod_php-4
(4.0.6), Apache/1.3.19 (Unix) (SuSE/Linux), MySQL 3.23.43 ,and there it runs
perfectly:
Here is the script:
=
?php
Version 0.1
hcms_fe_engine.php
( Frontendengine )
Gibt den Inhalt der Site für WebUser aus
/
// Sessionverwaltung einbinden
include ('hcms_fe_session.php');
// Allgemeine Konfiguration einbinden
include('hcms.init.php');
// Datenbankschnittstelle einbinden
include ('hcms_smod_db.php');
// FE-Funktionen einbinden
include('hcms_fe_functions.php');
// Site-Konfiguration aus DB holen
$sConfig = getSiteConfig();
// Überprüfen, ob Site online ist
if ($sConfig[online] == n) {
header(Location: hcms_fe_siteoffline.html); // Ausweichdokument anzeigen
}
// Site ist online
else {
// Prüfung ob GenTime gewünscht
if ($sConfig[showgentime] === y) {
// Start der Erstellungsdauer
$timer = new cGenTime;
$timer-start();
}
/// ENDE Prüfung GenTime gewünscht
//
// Seiten-Code erzeugen
//
if (!isset($location)) {
$location = 1;
}
/// Seitenkopf generieren
echo(htmlheadtitle$sConfig[sitename]/title/headbody
bgcolor=\#66\);
include('layouts/site.css');
// Main-Layout-Tabelle generieren
echo (center
table class=bodytab cellpadding=0 cellspacing=0 border=0 width=800);
echo (trtd colspan=3 height=81img src=\.$IMG_SITE.logo_head.png\ border=0
width=800/td/tr);
echo(trtd colspan=3 height=10 valign=top width=800);
// Main-Menu aus DB holen
$mmenu = generate_menu(1,$location);
echo(table cellspacing=0 cellpadding=0 border=0 width=\800\
trtd class=conmenunbsp;nbsp;);^
for ($i = 1; $i = count($mmenu) - 1; $i++) {
echo($mmenu[$i]nbsp;nbsp;|nbsp;);
}
This is the part that crashes under Win2k
The 3. iteration of the loop. Not everytime, but often
echo(a href=hcms_admin_login_form.phpLogin/a);
echo (/tdtd class=conmenu align=right);echo(datum());echo(/tr/table);
echo(/td/tr);
// Kontextzeile einblenden
echo(trtd class=fecx align=
nbsp;nbsp;a href=\$PHP_SELF\img src=\pics_intern/news_haus.png\
border=0/a
nbsp;
a href=\mailto:$sConfig[webmaster]\;img
src=\pics_intern/news_umschlag.png\ border=0/a
/tdtd class=fecxfont color=whiteSie befinden sich font color=orangeb
/b/font );
echo(getCX($location, $cx));
echo(/font/tdtd class=fecxnbsp;/td/tr);
echo(trtd class=tdsmenu valign=\top\);
// Sub-Menu aus DB holen
get_subcats($location);
///
// Content aus DB holen
///
echo(nbsp;/tdtd class=tdcontent valign=top);
//
if (isset($cx) isset($idart)) {
$file = renderCat($cx, $idart);
include($DYN_PATH$file);
// Temporäre Inc-Datei nach Verwendung löschen
unlink($DYN_PATH$file);
}
elseif (isset($cx)) {
$file = renderCat($cx, );
include($DYN_PATH$file);
// Temporäre Inc-Datei nach Verwendung löschen
unlink($DYN_PATH$file);
} else {
$file = renderCat($location, );
include($DYN_PATH$file);
// Temporäre Inc-Datei nach Verwendung löschen
unlink($DYN_PATH$file);
}
echo(/td);
// ENDE Content aus DB holen
/
// Polls und Akutinfos aus DB holen
echo(td class=tdpoll);
echo(Poll);
echo(/td);
Ende Polls und Akutinfos aus DB holen
/
echo(/tr/table/centerbr);
/
/// Nochmalige Prüfung ob Timer gewünscht
if ($sConfig
[PHP-DEV] Fwd: can't build PHP_4_0_7 branch
Hm, it seems I'm not the only one having troubles compiling. I catched this one on php.install These are exact the same errors as I'm getting. --Jeroen Grigori Goronzy [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... I checked out the PHP_4_0_7 branch and tried running ./buildconf. I got: bash-2.05$ ./buildconf buildconf: checking installation... buildconf: autoconf version 2.52 (ok) buildconf: automake version 1.5 (ok) buildconf: libtool version 1.4 (ok) rebuilding Makefile templates rebuilding configure ./aclocal.m4:944: error: m4_defn: undefined macro: _m4_divert_diversion ./aclocal.m4:473: PHP_SUBST is expanded from... ./aclocal.m4:944: the top level rebuilding acconfig.h rebuilding main/php_config.h.in ./aclocal.m4:944: error: m4_defn: undefined macro: _m4_divert_diversion ./aclocal.m4:473: PHP_SUBST is expanded from... ./aclocal.m4:944: the top level autoconf: tracing failed bash-2.05$ same with php_4_0_7RC2 and RC3. What can I do? -greg -- 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 #13938 Updated: Windows-newlines are counted twice
ID: 13938 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Summary: Bad line numbers reported for parse errors Status: Open Bug Type: Scripting Engine problem Operating System: WinNT 4.0 PHP Version: 4.0.6 New Comment: I didn't say it wasn't a bug, I was trying to track down the problem. Changed summary. (the *nix php version handles winnewlines correctly) Previous Comments: [2001-11-09 10:17:41] [EMAIL PROTECTED] Yes, I am using Windows, and the Windows convention is CR+LF, while I guess the Unix convention is LF only. However, the Windows version of PHP should understand the difference, in fact version 4.0.4pl1 worked fine. I still consider this a bug. You are correct, the error in the script I was working on earlier this morning was very close to line 919. [2001-11-09 10:06:46] [EMAIL PROTECTED] You don't happen to use Windows newlines (I see your OS is windows)? Not that that _should_ matter, but it can be the source of the problem. Try to convert to unix newlines. I notice that with (n+1)/2 you get the actual line the error is on. In the long file, doesn't the error occur on line 919 by coincidence? [2001-11-09 06:33:17] [EMAIL PROTECTED] I should have said there are no EXTRA newlines. Of course there are newlines in the script :) [2001-11-09 06:32:18] [EMAIL PROTECTED] There are absolutely no newlines. In fact, at this very moment I am making changes to a web application, and am getting a parse error on line 1837 of a script which has only 1148 lines. [2001-11-05 21:43:29] [EMAIL PROTECTED] Can you check your file for newlines after the %. I can reproduce the error by putting 3 or 4 newlines at the end of the file after the closing tag. Because you are in a string, it errors when it reaches EOF. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=13938 Edit this bug report at http://bugs.php.net/?id=13938edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13900 Updated: date(I) does not correctly identify daylight saving time
ID: 13900 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Date/time related Operating System: Windows NT/XP PHP Version: 4.0.6 New Comment: On my w2k 4.0.4pl1, it returns 1, which is wrong now, since Daylight saving time ended a week ago in Europe. Same for debian-linux. Both are correctly configured. What's your output with this script: ?php var_dump(date(I, mktime(0,0,0,5,1,2001))); ? On my system, it returns string(1) 1 --Jeroen Previous Comments: [2001-11-03 01:09:15] [EMAIL PROTECTED] I downloaded 4.06 again and installed it manually. I have a feeling that my php.ini is somehow different than the standard because when I tried to use the optimized php.ini file I couldn't even load my script. But when I used the dist version the script worked (except for the date(I) part). I must have my PHP configured incorrectly. But why would it do it on two different computers and two different versions of PHP??? [2001-11-02 21:56:52] [EMAIL PROTECTED] Tried it from the command line and got all zeros. [2001-11-01 15:44:10] [EMAIL PROTECTED] You said you were running it as a CGI therefore my test should be equivalent without me having to use Apache. I don't see how the CGI being called through Apache could do this. BUT jic, please try executing your PHP CGI from the command line against those test scripts and see if you get the same results. -Chris [2001-11-01 15:32:35] [EMAIL PROTECTED] Well, I am getting zeros... I get in on PHP 4.06 on Windows XP pro and I get zeros on PHP 4.05 on Windows NT 4.0. both are running on Apache. Maybe that is the issue. Are you running PHP on Apache? [2001-11-01 14:13:27] [EMAIL PROTECTED] See http://bugs.php.net/bug.php?id=13888 for why the months are doubled. Here is my result from first script C:\phpphp t.php X-Powered-By: PHP/4.0.6 Content-type: text/html 11 All 1's not 0's. Second script 110 I have NO clue what it is doing on your box, mine is Windows XP RC2 I don't have access to any other windows version right now only Linux. Can someone else verify this on NT4? I am using the exact same PHP on XP as you. -Chris The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=13900 Edit this bug report at http://bugs.php.net/?id=13900edit=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-LANG] Feature or bug?
Yasuo wrote:
PHP does not report any errors for too many parameters for user
defined functions, both normal function and class method :(
Is PHP designed not to report error for this?
Too many parameters for a function is obvious error and any
language MUST report error for this, unless variable length of
parameters is allowed. IMO
php.lang is for language documumentation. Use php-dev for this kind of
issues.
And yes, that is intended. You need it when you do you own argument
handling:
function printall()
{
foreach (function_get_args() as $arg) {
echo "$arg\n";
}
}
--Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13839 Updated: mysql_db_query does converts EURO symbol
ID: 13839 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: MySQL related Operating System: Linux 2.2.18 PHP Version: 4.0.6 New Comment: CHeck the contents of your database with the mysql command line tool. If it really says amp;, post your session here. Mysql SELECT headline FROM article; ... Mysql Previous Comments: [2001-10-29 07:30:19] [EMAIL PROTECTED] It is not the problem of the character set. It is a matter of changing the data before it gets inserted into the database. example: the orginal string is #8364; the string that gets inserted by mysql_db_query is: amp;#8364; - the character gets encoded into amp;! Only the orginal string #8364; displays an EURO character with the browser if you read it from the database with php and display it in a HTML page. Is there a way to tell mysql_db_query() not to touch the string before inserting it into the database?? Thanks Martin [2001-10-26 15:44:55] [EMAIL PROTECTED] mysql uses a different character-set than your browser does. Therefor, it prints character 128 (the euro-sign) different than most text-processors. It is actually stored correctly, if you retrieve it (with i.e. PHP) and display it in your browser, it still is a euro-sign. [2001-10-26 11:15:08] [EMAIL PROTECTED] Try this $headline = This is a #8364; prize; mysql_db_query( $db, insert into article set headline='$headline'); this would insert the string This is a amp;#8364; prize! obviously the command mysql_db_query does a converting on the input string. But in this case the result would be a false string. Any help? Martin Edit this bug report at http://bugs.php.net/?id=13839edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #5360 Updated: Session not holding over.
ID: 5360
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Session related
Operating System: Red Hat Linux 6.1
PHP Version: 4.0.1pl2
New Comment:
POST is also supported. If you enable transparent-session-id propagation, PHP will
include a input type=hidden with the session name and id, and thus will work with
both POST and GET.
Where in the manual does it say that post isn't supported?
See 13841 for future updates about this problem, because it seems it's the same
problem after all.
Previous Comments:
[2000-07-27 21:04:20] [EMAIL PROTECTED]
reading the manual, php sessions support
a) GET
b) cookies
but if you want to use POST you can extract that post_var on another page and use
session_name() then
read the manual on session handling
[2000-07-07 19:59:10] [EMAIL PROTECTED]
I've tried this with IE and Netscape and it doesn't work:
http://216.235.251.8/login.phtml
TO USE: Initially you can just enter in anything you want. It will post to itself, the
session is started and the phpsessid variable is blank.
Then put anything else in the user and password fields and submit again. You'll see
the phpsessid populated with the previous ID but when the session_start is called, a
new ID is created and in the middle when I echo SID; it displays the string. The SID
macro is working and outputing information even though the cookie is being set,
contrary to the
documentation.
How do I know that the cookie is being set? Well, I look in my cookies.txt file and
find the cookie listed. (some may need to quit the browser before seeing the cookie in
the file).
[2000-07-04 17:33:17] [EMAIL PROTECTED]
This is a baffling problem. Perhaps I'm doing something wrong but I believe I'm doing
everything correct.
Here is an example script of what I'm talkinng about please save this in a file called
login.phtml or change the FORM tag to reflect the filename you choose.:
-
?
session_start();
if ($login) {
echo Posted Variable (echo \$PHPSESSID): . $PHPSESSID . BR;
//session_id($PHPSESSID);
echo session started (echo session_id()): . session_id() . BR;
session_register(user,pass);
echo Variable Registered in session (echo session_id()): . session_id() .
BR;
}
?HTML
HEAD
TITLELogin Testing/TITLE
/HEAD
BODY BGCOLOR=#FF
BRBR
Session display using echo SID;:? echo SID; ?BRBR
FORM METHOD=POST ACTION=login.phtml
form field populated using lt;? echo session_id(); ?gt;BR
Posting Variable: PHPSESSID: INPUT TYPE=TEXT NAME=PHPSESSID VALUE=? echo
session_id(); ? WIDTH=50BR
USER: INPUT TYPE=text NAME=userBR
PASS: INPUT TYPE=text NAME=passBR
INPUT TYPE=SUBMIT VALUE=login NAME=loginBR
/FORM
/BODY
/HTML
In this example, when session_start() is called, a new session variable is created. If
I you uncomment the line that forces the session ID back to what it should be, the
variables get registered in the proper session but when you echo SID it reverts to
the previous session and the $PHPSESSID is updated also to the new, incorrect,
session. This was done by testing under an SSL connection because this is where I
need to use it.
The installation is Apache 1.3.12+mod_ssl
One Curious thing:
If I change it the method to GET then this is what happens. at the first
initialization of the session it creates it, then when you submit the form, a new
session is created. But every post after that retains the session ID. Will this only
work via the GET method? I sincerely hope not because I need to keep the password
hidden.
Edit this bug report at http://bugs.php.net/?id=5360edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13842 Updated: Member variables in parent and child classes overwrite each other
ID: 13842
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Bogus
Bug Type: Class/Object related
Operating System: Windows NT 5.0 build 2195
PHP Version: 4.0.6
New Comment:
Alle class vars are public, in a future PHP (5?) there will also be private object
vars.
Until then, object vars of children and parents are simply the same, and thus
overwrite eachother. This is intended behavior.
Not a bug.
Previous Comments:
[2001-10-27 01:37:46] [EMAIL PROTECTED]
Works fine for me with latest CVS. Please try the
development build from http://www.php4win.com/
--Jani
[2001-10-26 17:52:30] [EMAIL PROTECTED]
I'm not all that familiar with PHP, so it's possible I haven't understood something
that should be obvious, or have mistyped something. But assuming that's not the case:
To my eye this makes using someone else's classes via inheritence a wee bit dangerous,
and makes using inheritence at all somewhat problematic since changing a class that
exists in an inheritence makes one liable to create subtle bugs in code that one has
not modified - which defeats one of the (possibly the most) principal purposes of OO.
If I could make a suggestion: support of 'private' and 'public' for member variables
might be a good thing. Especially if access defaulted to 'private' and that meant that
the variable was only visible to the immediate class.
Using the CGI binary without modification running on Microsoft-IIS/5.0 I used the
following test script:
html
head
titleInheritence Bug/title
/head
body
?php
//=
// NOTE:
// Bad behaviour if C2 extends C1, Correct if C2 extends C1_1
class C2 extends C1_1
{
var $m_sMe = C2; // ERROR: this
overwrites parent
var $m_sIniter = ;
function C2( $sIniter=)
{
$this-m_sIniter = $sIniter;// OK - by defn
parent::C1( $this-m_sMe); // OK - the way to do
it
}
function WhoIsIt()
{
printf( C2::WhoIsIt() : This is: . $this-m_sMe .
br\n);
printf( Inited by: . $this-m_sIniter . br\n);
parent::WhoIsIt();
}
}
//=
class C1_1
{
var $m_sMe_1 = C1;
var $m_sIniter_1 = ;
function C1( $sIniter=)
{
print( (OK)br\n);
$this-m_sIniter_1 = $sIniter;
}
function WhoIsIt()
{
printf( C1::WhoIsIt() : This is: . $this-m_sMe_1 .
br\n);
printf( Inited by: . $this-m_sIniter_1 . br\n);
}
function ResetBase()
{
$this-m_sMe_1 = C1;
printf( C1::ResetBase() : This is: . $this-m_sMe_1 .
br\n);
printf( Inited by: . $this-m_sIniter_1 . br\n);
}
}
//=
class C1
{
var $m_sMe = C1;
var $m_sIniter = ;
function C1( $sIniter=)
{
print( (Bad)br\n);
$this-m_sIniter = $sIniter;// ERROR: this overwrites
child's value
}
function WhoIsIt()
{
printf( C1::WhoIsIt() : This is: . $this-m_sMe .
br\n);
printf( Inited by: . $this-m_sIniter . br\n);
}
function ResetBase()
{
$this-m_sMe = C1;
printf( C1::ResetBase() : This is: . $this-m_sMe .
br\n);
printf( Inited by: . $this-m_sIniter . br\n);
}
}
//=
$test = new C2( Doug);
$test-WhoIsIt();
//$test-ResetBase();
?
p
In case there is a platform dependency, this is what I consider correct output:br
pre
C2::WhoIsIt() : This is: C2
Inited by: Doug
C1::WhoIsIt() : This is: C1
Inited by: C2
/pre
/p
/body
/html
Edit this bug report at http://bugs.php.net/?id=13842edit=1
--
PHP Development
[PHP-DEV] Bug #13848 Updated: transparent sessions not w3c compliant
ID: 13848 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: URL related Operating System: Linux PHP Version: 4.0.4pl1 New Comment: Shouldn't amp; be made the default? Since that's the only correct thing, and at least since HTML 2.0 amp;-style quoting was required. Or are there browsers doing it wrong? Bad browsers in that case, but it could be a reason to not change the default: Apache for examples has also some workarounds in their default httpd.conf for buggy browsers. Previous Comments: [2001-10-28 10:36:50] [EMAIL PROTECTED] This applies to PHP 4.0.6 and above. So update first. --Jani [2001-10-27 09:15:13] [EMAIL PROTECTED] Not a bug, see this part from php.ini-recommended: ; The separator used in PHP generated URLs to separate arguments. ; Default is . ;arg_separator.output = amp; [2001-10-27 09:08:38] [EMAIL PROTECTED] transparent sessions don't appear to be w3c compliant, in that when a url is not cookied, it appears as, eg a href=index.php?id=xyzPHPSESSION=3982982 where it should be a href=index.php?id=xyzamp;PHPSESSION=3982982 see http://www.htmlhelp.com/tools/validator/problems.html#amp Edit this bug report at http://bugs.php.net/?id=13848edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13850 Updated: CASE within SWITCH may crash apache
ID: 13850
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Status: Feedback
Old Bug Type: Documentation problem
Bug Type: Scripting Engine problem
Operating System: Windows 2000 Pro SP1
PHP Version: 4.0.4
New Comment:
Reclassified.
Please also be more specific on the error, are you saying it crashes? What's the html
output? Could you post the URL here?
Previous Comments:
[2001-10-28 11:17:46] [EMAIL PROTECTED]
Unable to reproduce with 4.0.3pl1 or latest dev on linux, and also I can't reproduce
on 4.0.4pl1 on windows.
I get (correctly) a parse error on (incorrectly, but known 'feature') the line with
the switch.
Please try to upgrade, use at least 4.0.4pl1 and not 4.0.4.
[2001-10-27 13:12:45] [EMAIL PROTECTED]
The following script raised an error in apache (1.3.19)permantly. The error message
describes an Memory Write Problem.
The reason are the operators after CASE. If they are removed
the script runs without errors.
The error can be reproduced.
I've tried it with different activated modules in PHP but the problem persists.
I think it should be better to put this into the documentation.
?php
$foo = 20
switch($foo)
{
case 50:
echo Less than 50;
break;
case 50 100
echo Between 50 and 100;
break;
default:
echo 100;
break;
}
?
Edit this bug report at http://bugs.php.net/?id=13850edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13852 Updated: zlib file reading functions not working in Apache Module version
ID: 13852
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Zlib Related
Operating System: Windows 2000
PHP Version: 4.0.4pl1
New Comment:
Probably not a bug (cgi does work, so very unlikely to be a bug in PHP or zlib). Ask
support questions on http://www.php.net/support.php , or reopen if I'm wrong.
Try this:
Please check the location of your php.ini, that you're editing the right one. (check
wether modifications show up in a phpinfo() page).
And check your error reporting level, set it to E_ALL (error_reporting(E_ALL); before
anything). My guess is it's giving undefined function errors.
Previous Comments:
[2001-10-27 16:58:01] [EMAIL PROTECTED]
most of the zlib file reading functions, like gzfile,gzread,gzpassthru,gzgetc do not
work in the Apache Module version of php.
the function returns no value - without outputting any error or warning; sometimes the
webserver crashes.
when i switched php to run as cgi everything works as expected.
don't know if this has been fixed, couldn't find an entry in the bugfinder.
phil.
running extensions:
extension=php_zlib.dll
extension=php_sablot.dll
extension=php_gd.dll
extension=php_pdf.dll
demo script (test.gz would be ascii text):
$log = gzfile('test.gz');
foreach ($log as $l) echo $lbr;
Edit this bug report at http://bugs.php.net/?id=13852edit=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: Bug #13842 Updated: Member variables in parent and child classes overwrite each other
Pleaes use the web interface for updating bugs!
I missed this mail until now.
--Jeroen
- Original Message -
From: Doug Plant [EMAIL PROTECTED]
Newsgroups: php.dev
To: [EMAIL PROTECTED]
Sent: Sunday, October 28, 2001 4:38 AM
Subject: Re: Bug #13842 Updated: Member variables in parent and child
classes overwrite each other
Hi,
Thanks for the reply. Still looks bad.
My mistake, but I left the script in it's good configuration. If you
change the line:
class C2 extends C1_1
To:
class C2 extends C1
the the bad behaviour is shown. I left the line in the former state.
Doug
From: Bug Database [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Bug #13842 Updated: Member variables in parent and child classes
overwrite each other
Date: 27 Oct 2001 05:37:46 -
ID: 13842
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Class/Object related
Operating System: Windows NT 5.0 build 2195
PHP Version: 4.0.6
New Comment:
Works fine for me with latest CVS. Please try the
development build from http://www.php4win.com/
--Jani
Previous Comments:
[2001-10-26 17:52:30] [EMAIL PROTECTED]
I'm not all that familiar with PHP, so it's possible I haven't understood
something that should be obvious, or have mistyped something. But
assuming
that's not the case:
To my eye this makes using someone else's classes via inheritence a wee
bit
dangerous, and makes using inheritence at all somewhat problematic since
changing a class that exists in an inheritence makes one liable to create
subtle bugs in code that one has not modified - which defeats one of the
(possibly the most) principal purposes of OO.
If I could make a suggestion: support of 'private' and 'public' for
member
variables might be a good thing. Especially if access defaulted to
'private' and that meant that the variable was only visible to the
immediate class.
Using the CGI binary without modification running on Microsoft-IIS/5.0
I
used the following test script:
html
head
titleInheritence Bug/title
/head
body
?php
file://=
// NOTE:
// Bad behaviour if C2 extends C1, Correct if C2 extends C1_1
class C2 extends C1_1
{
var $m_sMe = C2; // ERROR: this overwrites parent
var $m_sIniter = ;
function C2( $sIniter=)
{
$this-m_sIniter = $sIniter; // OK - by defn
parent::C1( $this-m_sMe); // OK - the way to do it
}
function WhoIsIt()
{
printf( C2::WhoIsIt() : This is: . $this-m_sMe . br\n);
printf( Inited by: . $this-m_sIniter . br\n);
parent::WhoIsIt();
}
}
file://=
class C1_1
{
var $m_sMe_1 = C1;
var $m_sIniter_1 = ;
function C1( $sIniter=)
{
print( (OK)br\n);
$this-m_sIniter_1 = $sIniter;
}
function WhoIsIt()
{
printf( C1::WhoIsIt() : This is: . $this-m_sMe_1 . br\n);
printf( Inited by: . $this-m_sIniter_1 . br\n);
}
function ResetBase()
{
$this-m_sMe_1 = C1;
printf( C1::ResetBase() : This is: . $this-m_sMe_1 . br\n);
printf( Inited by: . $this-m_sIniter_1 . br\n);
}
}
file://=
class C1
{
var $m_sMe = C1;
var $m_sIniter = ;
function C1( $sIniter=)
{
print( (Bad)br\n);
$this-m_sIniter = $sIniter; // ERROR: this overwrites child's value
}
function WhoIsIt()
{
printf( C1::WhoIsIt() : This is: . $this-m_sMe . br\n);
printf( Inited by: . $this-m_sIniter . br\n);
}
function ResetBase()
{
$this-m_sMe = C1;
printf( C1::ResetBase() : This is: . $this-m_sMe . br\n);
printf( Inited by: . $this-m_sIniter . br\n);
}
}
file://=
$test = new C2( Doug);
$test-WhoIsIt();
file://$test-ResetBase();
?
p
In case there is a platform dependency, this is what I consider correct
output:br
pre
C2::WhoIsIt() : This is: C2
Inited by: Doug
C1::WhoIsIt() : This is: C1
Inited by: C2
/pre
/p
/body
/html
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=13842edit=2
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--
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] Suggestion RFC: Bug db mails
Hi, Suggestion: set the From: of bug-mails to [EMAIL PROTECTED], and put a autoresponer over there asking the user again to use the web interface in stead of replying, and possibly don't give the php-dev mail at all, or as 'only for ...'. --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13094 Updated: Upload very slow
ID: 13094
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Assigned
Status: Closed
Bug Type: Performance problem
Operating System: Windows 2000
PHP Version: 4.0.6
Assigned To: sniper
New Comment:
Fixed in CVS by Jani, will be fixed in 4.2.0
Previous Comments:
[2001-09-02 16:52:23] [EMAIL PROTECTED]
Work in progress...
[2001-09-02 11:57:36] [EMAIL PROTECTED]
This has nothing to do with 2291.
The problem probably is that PHP takes all HTTP-post data into it's memory, and only
after the complete header (WITH all files) are in-memory, php_mime_split is called to
get the files out of the request and save them to disk.
So if you need to recieve file-uploads of 100MB or something, PHP needs 100MB of
RAM... otherwise it will swap and thus be terribly slow (especially on Windows)
A real solution would be to rewrite php_mime_split to run on-the-fly... which at first
glance isn't terribly hard.
[2001-09-02 11:17:11] [EMAIL PROTECTED]
Seems duplicate of 2291, but that one should be fixed in 4.0.6
[2001-09-02 07:34:53] [EMAIL PROTECTED]
?php
if(is_uploaded_file($userfile))
{
$FileNameAdd = $FileName;
//Prefix for filename using uniqid();
$FileNameAddDB = $DBFileName; //Including prefix
used for database
$filename = $HTTP_POST_FILES['userfile']['name']; //Filename as selected
by user
$FileExt = substr(strrchr($filename, .), 1);
if(array_search($FileExt, $Extensions) == FALSE)
{
?
font class=warningNot allowed to upload this file./font
?php
exit();
}
$DBFileSize = $HTTP_POST_FILES['userfile']['size'];
$DBFileName = $FileNameAddDB.$filename;
move_uploaded_file($userfile, $Mapping . $FileNameAdd.$filename);
?
Didn't compile anything just use the compiled version as download from website.
When I upload a file bigger than 10 MB, it takes a very long time (if it uploads) I
adjusted all the needed variables in php.ini.
I'm using it for files (150MB) over a Lan network.
I've tried a ASP uploader and it does the same file in less then three minutes. PHP
was working for 30 minutes and still wasn't done.
I think this is a bug in the code.
Marcel van Leeuwen
Netherlands
Edit this bug report at http://bugs.php.net/?id=13094edit=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] Bug #13094 Updated: Upload very slow
Please leave alone these. I was going to close them myself as I want to add some information to them too.. I'm sorry, you committed the fix yesterday early, and I thought you might have forgotten them. (but should've know better) I should've mailed you instead, I got a 'then this bug is fixed or not?' mail from the submitter. --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13859 Updated: Change (string)false from to 0
ID: 13859 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Summary: Inconsistent display of logical results Old Status: Open Status: Closed Old Bug Type: Performance problem Bug Type: Feature/Change Request Operating System: Windows95 PHP Version: 4.0.6 New Comment: Reclassified and updated summary. But it's not going to happen, therefore closed. There are numerous reasons for todays behaviour. use var_dump anyway if you are interested in the value of an expression, and/or if() or something alike if you want to use the truth value of a variable. See also: http://www.php.net/types Previous Comments: [2001-10-28 12:22:40] [EMAIL PROTECTED] ?php $n1=10; $n2=8; echo '$n1$n2 is '.($n1$n2).br; echo '$n1=$n2 is '.($n1=$n2).br; echo '$n1$n2 is '.($n1$n2).br; echo '$n1=$n2 is '.($n1=$n2).br; echo '$n1==$n2 is '.($n1==$n2).br; echo '$n1!=$n2 is '.($n1!=$n2).br; echo '$n1$n2 is '.($n1$n2).br; echo '$n1===$n2 is '.($n1===$n2).br; echo '$n1!==$n2 is '.($n1!==$n2).br; echo br; $bool=($n1==$n2 || $n1===$n2); echo '$bool=($n1==$n2 || $n1===$n2);'.br; echo '$bool is '.$bool; ? --- This code is a simple run-through of the logical operators. The problem is that 0 is never displayed normally, but if you use boolean logic, then it is possible for 0 to be displayed. I prefer the 0 being displayed. Edit this bug report at http://bugs.php.net/?id=13859edit=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] Bug #13846 Updated: Patch: Use [ ] as shortcut forarray()
On Sun, 28 Oct 2001, Zakaria wrote:
For example:
Perl: $list = (1, 2 ,3, 'four', 'five', (6.1, 6.2, 6.3));
Python: list = [1, 2, 3, 'four', 'five', [6.1, 6.2, 6.3]]
Ruby: list = [1, 2, 3, 'four', 'five', [6.1, 6.2, 6.3]]
Tcl: set list {1 2 3 four five {6.1 6.2 6.3}}
PHP: $list = array(1, 2, 3, 'four', 'five', array(6.1, 6.2, 6.3));
Which clearly shows that PHP is readable and all the other languages are
not. -10 from me to this feature.
And these example are still a bit readable, but what about:
$arr1 = [];
$arr2[10] = [2];
$foo = bla('arg1', [2, 3, 4]);
and such cases...
So indeed a bad idea.
--Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13860 Updated: Bzip2 bzdecompress function is wery slow...
ID: 13860 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Old Bug Type: Bzip2 Related Bug Type: Performance problem Operating System: Windows 98 SE PHP Version: 4.0.6 New Comment: Please don't but multiple issues in one report, and keep your report short. (bugs do's and don'ts) I'm transforming this report into performance question of bzip, open a new feature/change request on the second parameter. you use bzdecompress(..., TRUE), i.e. you tell it to be two times slower... Then you shouldn't complain about performance, bzip is very strong compression at the cost of high memory and cpu usage. And you read the whole file in memory, decompress it, write it back to disk... that's very inefficient. So this is not a bug in PHP, but a problem with your script. Ask http://www.php.net/support.php for support questions on how to do things efficiently. Compressing JPG's is a quite useless practice by the way... jpg is already compressed. Previous Comments: [2001-10-28 15:57:28] [EMAIL PROTECTED] bzdecompress($ecd_cont,1); I'm used it without the 1 parameter, i'm just tryed uot what happen if i use it... [2001-10-28 15:34:18] [EMAIL PROTECTED] I made a little decompresser script: ?php $efilename = d:/pic.bz2; //A compressed jpg image ( original size: 388kbyte, packed size: 388kbyte) $ufilename2 = d:/pic.jpg; $fp = fopen($efilename, rb); $ecd_cont = fread($fp, filesize($efilename)); //read the compressed data from file fclose($fp); $fp = fopen($ufilename2,wb); $ecd_cont = bzdecompress($ecd_cont,1); //decompress the readed compressed data fwrite($fp, $ecd_cont); //write the decompressed data into file fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok, this is work... But it is WERY WERY slow!!! It's take 60sec to display the decompressed image, why?? I made the decompression befor with an other method: ?php $efilename = d:/pic.bz2; $ufilename2 = d:/pic.jpg; $bz = bzopen($efilename, rb); $ecd_cont = bzread($bz, 40); // See below bzlose($bz); $fp = fopen($ufilename2,wb); fwrite($fp, $ecd_cont); fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok this is working (And this is fast! The decompressed picture appears immediately), but there is a little problem: In the PHP manual I read this about the bzread() function: If the optional parameter length is not specified, bzread() will read 1024 (uncompressed) bytes at a time. Ok, so it will read 1024 uncompressed bytes from my compressed file, if I not give the lenght parameter (as I did in the example). But there is a problem: if I want to be precise then I must give the lenght of the original file, but how??? I only have the compressed file, which is not equal with the original (ok, in my example it is, but only because the original jpg-compressed file), so I cant use the filesize() function, because it gave only the compressed filesize, neither the strlen() because I havnt got a string yet :) And I think you agree with me if I dont want to write 400Mbyte to parameter... this is not a correct solution. I think the correct solution if the bzread() function is read the entire file if I dont give the lenght parameter. Edit this bug report at http://bugs.php.net/?id=13860edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13860 Updated: Bzip2 bzdecompress function is wery slow...
ID: 13860 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status: Bogus Status: Assigned Bug Type: Performance problem Operating System: Windows 98 SE PHP Version: 4.0.6 Old Assigned To: Assigned To: jeroen New Comment: Reopened, the current implementation of bzdecompress is extremely inefficient. Assigned to myself. Previous Comments: [2001-10-28 20:01:28] [EMAIL PROTECTED] you use bzdecompress(..., TRUE), i.e. you tell it to be two times slower... Then you shouldn't complain about performance, bzip is very strong compression at the cost of high memory and cpu usage. As I said in my comment I just tried what happen if I use the True parameter. I used the script without that parameter and it was slow... And you read the whole file in memory, decompress it, write it back to disk... that's very inefficient. Interesting. But I did the same in my older version of decompression script and it was fast... I dont sure why there is this differnece in the speed between the bzwrite() and the bzdecompress() functions. Btw I think I have a fast PC, a simple decompression like this should not take more than two or there secounds... Compressing JPG's is a quite useless practice by the way... jpg is already compressed. Of course I know jpg is already compressed... but this is a wery good way to test my script... If it works i can see the result immediately (the img at the and of the script). Is it satisfie you if I use pic.bmp next time? :) [2001-10-28 16:27:24] [EMAIL PROTECTED] Please don't but multiple issues in one report, and keep your report short. (bugs do's and don'ts) I'm transforming this report into performance question of bzip, open a new feature/change request on the second parameter. you use bzdecompress(..., TRUE), i.e. you tell it to be two times slower... Then you shouldn't complain about performance, bzip is very strong compression at the cost of high memory and cpu usage. And you read the whole file in memory, decompress it, write it back to disk... that's very inefficient. So this is not a bug in PHP, but a problem with your script. Ask http://www.php.net/support.php for support questions on how to do things efficiently. Compressing JPG's is a quite useless practice by the way... jpg is already compressed. [2001-10-28 15:57:28] [EMAIL PROTECTED] bzdecompress($ecd_cont,1); I'm used it without the 1 parameter, i'm just tryed uot what happen if i use it... [2001-10-28 15:34:18] [EMAIL PROTECTED] I made a little decompresser script: ?php $efilename = d:/pic.bz2; //A compressed jpg image ( original size: 388kbyte, packed size: 388kbyte) $ufilename2 = d:/pic.jpg; $fp = fopen($efilename, rb); $ecd_cont = fread($fp, filesize($efilename)); //read the compressed data from file fclose($fp); $fp = fopen($ufilename2,wb); $ecd_cont = bzdecompress($ecd_cont,1); //decompress the readed compressed data fwrite($fp, $ecd_cont); //write the decompressed data into file fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok, this is work... But it is WERY WERY slow!!! It's take 60sec to display the decompressed image, why?? I made the decompression befor with an other method: ?php $efilename = d:/pic.bz2; $ufilename2 = d:/pic.jpg; $bz = bzopen($efilename, rb); $ecd_cont = bzread($bz, 40); // See below bzlose($bz); $fp = fopen($ufilename2,wb); fwrite($fp, $ecd_cont); fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok this is working (And this is fast! The decompressed picture appears immediately), but there is a little problem: In the PHP manual I read this about the bzread() function: If the optional parameter length is not specified, bzread() will read 1024 (uncompressed) bytes at a time. Ok, so it will read 1024 uncompressed bytes from my compressed file, if I not give the lenght parameter (as I did in the example). But there is a problem: if I want to be precise then I must give the lenght of the original file, but how??? I only have the compressed file, which is not equal with the original (ok, in my example it is, but only because the original jpg-compressed file), so I cant use the filesize() function, because it gave only the compressed filesize, neither the strlen() because I havnt got a string yet :) And I think you agree with me if I dont want to write 400Mbyte to parameter... this is not a correct solution. I think the correct solution if the bzread() function is read the entire file if I dont give the lenght parameter. Edit this bug report at http://bugs.php.net/?id=13860edit=1 -- PHP
[PHP-DEV] Bug #13860 Updated: Bzip2 bzdecompress function is wery slow...
ID: 13860 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status: Assigned Status: Closed Bug Type: Performance problem Operating System: Windows 98 SE PHP Version: 4.0.6 Assigned To: jeroen New Comment: Fixed in CVS, will be in 4.2.0 Memory requirements are also lower now, as is for bzcompress. Previous Comments: [2001-10-28 20:31:25] [EMAIL PROTECTED] Reopened, the current implementation of bzdecompress is extremely inefficient. Assigned to myself. [2001-10-28 20:01:28] [EMAIL PROTECTED] you use bzdecompress(..., TRUE), i.e. you tell it to be two times slower... Then you shouldn't complain about performance, bzip is very strong compression at the cost of high memory and cpu usage. As I said in my comment I just tried what happen if I use the True parameter. I used the script without that parameter and it was slow... And you read the whole file in memory, decompress it, write it back to disk... that's very inefficient. Interesting. But I did the same in my older version of decompression script and it was fast... I dont sure why there is this differnece in the speed between the bzwrite() and the bzdecompress() functions. Btw I think I have a fast PC, a simple decompression like this should not take more than two or there secounds... Compressing JPG's is a quite useless practice by the way... jpg is already compressed. Of course I know jpg is already compressed... but this is a wery good way to test my script... If it works i can see the result immediately (the img at the and of the script). Is it satisfie you if I use pic.bmp next time? :) [2001-10-28 16:27:24] [EMAIL PROTECTED] Please don't but multiple issues in one report, and keep your report short. (bugs do's and don'ts) I'm transforming this report into performance question of bzip, open a new feature/change request on the second parameter. you use bzdecompress(..., TRUE), i.e. you tell it to be two times slower... Then you shouldn't complain about performance, bzip is very strong compression at the cost of high memory and cpu usage. And you read the whole file in memory, decompress it, write it back to disk... that's very inefficient. So this is not a bug in PHP, but a problem with your script. Ask http://www.php.net/support.php for support questions on how to do things efficiently. Compressing JPG's is a quite useless practice by the way... jpg is already compressed. [2001-10-28 15:57:28] [EMAIL PROTECTED] bzdecompress($ecd_cont,1); I'm used it without the 1 parameter, i'm just tryed uot what happen if i use it... [2001-10-28 15:34:18] [EMAIL PROTECTED] I made a little decompresser script: ?php $efilename = d:/pic.bz2; //A compressed jpg image ( original size: 388kbyte, packed size: 388kbyte) $ufilename2 = d:/pic.jpg; $fp = fopen($efilename, rb); $ecd_cont = fread($fp, filesize($efilename)); //read the compressed data from file fclose($fp); $fp = fopen($ufilename2,wb); $ecd_cont = bzdecompress($ecd_cont,1); //decompress the readed compressed data fwrite($fp, $ecd_cont); //write the decompressed data into file fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok, this is work... But it is WERY WERY slow!!! It's take 60sec to display the decompressed image, why?? I made the decompression befor with an other method: ?php $efilename = d:/pic.bz2; $ufilename2 = d:/pic.jpg; $bz = bzopen($efilename, rb); $ecd_cont = bzread($bz, 40); // See below bzlose($bz); $fp = fopen($ufilename2,wb); fwrite($fp, $ecd_cont); fclose($fp); echo img src=\file://d:\\pic.jpg\; ? Ok this is working (And this is fast! The decompressed picture appears immediately), but there is a little problem: In the PHP manual I read this about the bzread() function: If the optional parameter length is not specified, bzread() will read 1024 (uncompressed) bytes at a time. Ok, so it will read 1024 uncompressed bytes from my compressed file, if I not give the lenght parameter (as I did in the example). But there is a problem: if I want to be precise then I must give the lenght of the original file, but how??? I only have the compressed file, which is not equal with the original (ok, in my example it is, but only because the original jpg-compressed file), so I cant use the filesize() function, because it gave only the compressed filesize, neither the strlen() because I havnt got a string yet :) And I think you agree with me if I dont want to write 400Mbyte to parameter... this is not a correct solution. I think the correct solution if the bzread() function is read the entire file
[PHP-DEV] Bug #13799 Updated: PHP selects rows correctly but adds them up wrong
ID: 13799 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: MySQL related Operating System: Windows 98 PHP Version: 4.0.6 New Comment: Not a bug in PHP. Mysql handles distinct count(*) wrong, iirc it's noted on their website. PHPmyAdmin could work around this, but that's not the business of PHP. You could drop a line over there. no bug in php - bogus Previous Comments: [2001-10-23 09:51:55] [EMAIL PROTECTED] I am accessing my database through phpMyAdmin-2.2.0 and not through my own script - so I know it is not any fault of my scripting abilities! I obtained my copy of the script from SourceForge (http://sourceforge.net/projects/phpmyadmin/) On reflection, you guys might not have written this so perhaps I should report the bug to SourceForge... if this is the case then please accept my apologies and I will report the bug to SourceForge. Regards Jonathan [2001-10-23 09:02:45] [EMAIL PROTECTED] Probably not a bug in PHP, but in your script. Can you provide a sample script? [2001-10-23 08:46:49] [EMAIL PROTECTED] Using MySQL through the Apache server with a reproduction of the Northwind database (as supplied by MicroSoft). The command: SELECT DISTINCT Customers.* FROM Customers, Orders WHERE Customers.CustomerID = Orders.CustomerID; This works OK when executed by MySQL in DOS (returning 20 records in my version of the Northwind Database). In PHP the command also returns 20 records but PHP incorrectly reports Showing records 0-30 (387) at the top of the page. If I leave out the 'DISTINCT' command I get the full 387 records with a correct report Showing records 0-30 (387). I amend the query as follows: SELECT DISTINCT Customers.* FROM Customers, Orders WHERE Customers.CustomerID = Orders.CustomerID ORDER BY Customers.CustomerID; PHP now shows the same 20 records and declares Showing records 0-20 (20) this time correctly. Edit this bug report at http://bugs.php.net/?id=13799edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13792 Updated: just another test, IGNORE!
ID: 13792 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *General Issues Operating System: bogus PHP Version: 4.0.6 New Comment: Updated: test wether accidental reposting of comments is also prevented... Previous Comments: [2001-10-22 17:58:22] [EMAIL PROTECTED] Okay, it works. :) [2001-10-22 17:55:31] [EMAIL PROTECTED] Blaah. Edit this bug report at http://bugs.php.net/?id=13792edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13792 Updated: just another test, IGNORE!
ID: 13792 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *General Issues Operating System: bogus PHP Version: 4.0.6 New Comment: Updated: test wether accidental reposting of comments is also prevented... Previous Comments: [2001-10-23 16:56:04] [EMAIL PROTECTED] Updated: test wether accidental reposting of comments is also prevented... [2001-10-22 17:58:22] [EMAIL PROTECTED] Okay, it works. :) [2001-10-22 17:55:31] [EMAIL PROTECTED] Blaah. Edit this bug report at http://bugs.php.net/?id=13792edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12567 Updated: file_exists('') === NULL
ID: 12567
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Filesystem function related
Operating System:
PHP Version: 4.0.6
New Comment:
It should be FALSE.
Previous Comments:
[2001-10-20 21:15:20] [EMAIL PROTECTED]
What is the bug here?
[2001-08-04 16:52:36] [EMAIL PROTECTED]
file_exists('') === NULL
Edit this bug report at http://bugs.php.net/?id=12567edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13782: ctpublic.h not found while compiling (configure should detect it)
From: [EMAIL PROTECTED] Operating system: any PHP version: 4.1.0RC1 PHP Bug Type: Compile Failure Bug description: ctpublic.h not found while compiling (configure should detect it) The configure script doesn't check for ctpublic.h which on debian is found in freetds-dev :) freetds-dev: /usr/include/ctpublic.h -- Edit bug report at: http://bugs.php.net/?id=13782edit=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] Fw: [PATCH] Fix for inconsistent float-int converting
On Fri, 19 Oct 2001, Stig S. Bakken wrote: Hm, another way to deal with overflows could be returning null, if it's acceptable to return a different type than expected at least. With 0 or max/min, it won't be possible for a program to detect overflows. With null it would be. I like this idea... But when you do (int)$bla, you really expect an integer... and not null. Still, is null maybe acceptable? ZeevAndi? This reminds me of another suggesting I made: the (number) cast. It will convert to int if possible, float otherwise. Third point: Currently casting array to a number, it will be 1 if non-empty, zero if empty. IMHO, it is more logical to simply return the number of elements. It is BC, since boolean checks for array will still yield false iff array is empty. (I'm - of course - open for discussion on these things) --Jeroen - Stig Jeroen van Wolffelaar wrote: On Fri, 19 Oct 2001, Stig S. Bakken wrote: In cases like these I think PHP should do whatever C does. There's no point in trying to be clever when casts overflow. In C, when you doe int i;, i will contain random data. In PHP, a variable will always be cleared (to null). In C, when you cast a out-of-range-float, I doubt wether it's defined. Furthermore, PHP is not C, so I see no reason to follow C just like that. What do you expect from trying to store a too big float in an integer? I expect an error, and the nearest valid result. I really see no logic in the current behavior, only that it makes a limited amount of unsigned-int faking possible. But floats are floats, that's not going well all the time (see the numerous bugreports on this kind of gotcha's). So also for this reason I believe there should be no such wrapping behaviour, as it might lead people to think unsigned ints are supported, resulting in very strange things. Especially the E_NOTICE when this happens will help a lot of people IMO. In the case of casting larger integers into smallers, it's differnt because you're talking about _intgers_ then, and not floats. --Jeroen - Stig Jeroen van Wolffelaar wrote: Resent, due to lack of feedback from my side ;) Andi replied: Why is it more correct to convert it to min/max values? I can't think of a case where this would make more sense to the developer. Also, there is a reason for the cast to unsigned int if the value is bigger that LONG_MAX. I think it makes sense. If a float is out-of-range, it can usually not be mod'd by 2**32, due to the nature of floats. Therefore, the only consistent way would be going to the nearest integer possible. Okay, because on most systems floats happen to be more precise than int's, you _can_ mod them by 2**32, but there is a quite significant possibility of having rounding errors. You cannot do integer-precision with floats. And it's inconsistent too, PHP int's are ranging from -2**31 to (2**31)-1, there is no such thing as unsigned integers. So why convert the float 3e9 to something way below zero? Additionally, a notice is a good idea here, just like what happens on division by zero: the most natural result is returned, and a notice is issued. --Jeroen - Original Message - From: Jeroen van Wolffelaar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 02, 2001 2:39 AM Subject: [PATCH] Fix for inconsistent float-int converting When a too-large float is converted to integer, it happens in a quite random way. When float is out of range, PHP should stick to the min resp. max values of integer. This patch will achieve this, I tested it succesfully. --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen Name: double.diff double.diffType: unspecified type (application/octet-stream) Encoding: quoted-printable -- 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] Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13741 Updated: Cannot walk the same associative array twice in the same script
ID: 13741
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Arrays related
Operating System: FreeBSD 4.2-RELEASE
PHP Version: 4.0.6
New Comment:
And you should be using foreach anyway in this case.
Previous Comments:
[2001-10-19 06:38:32] [EMAIL PROTECTED]
... or read the documentation on each() itself:
[...]
After each() has executed, the array cursor will be left on the next element of the
array, or on the last element if it hits the end of the array
[...]
[2001-10-19 06:35:15] [EMAIL PROTECTED]
see http://php.net/reset
[2001-10-19 06:19:43] [EMAIL PROTECTED]
I have a simple associative array of scalar name/value
pairs -- specifically, the 50 US states and their
abbreviations. The array is sorted using asort().
Two places in my script, I walk the array using the
list/each syntax:
while(list($abbr,$name) = each($STATES_HASH))
{
...
}
The first time, everything works as it should. All
subsequent times however (within the same script) the
array acts as though it's blank. If I query the size using
sizeof(), it reports the correct value. If I try to
extract values from the array, it works fine. If I make a
copy of the array to a new variable, the copy works
properly (the first time).
It seems like there's a bug in the each() function. Looks
almost as if every associative array has a pointer to the
current element that's not getting reset when each() is
done with it.
My configure line is as follows:
'./configure' '--prefix=/usr/local/php-4.0.6'
'--with-apache=../apache_1.3.19'
'--with-pgsql=/usr/local/pgsql' '--enable-track-vars'
'--with-config-file-path=/etc'
'--with-jpeg-dir=/usr/local' '--with-tiff-dir=/usr/local'
'--with-png-dir=/usr/local' '--with-zlib-dir=/usr/local'
'--with-pdflib=/usr/local'
Edit this bug report at http://bugs.php.net/?id=13741edit=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: Bug #13748 Updated: Exec() and System() broken
ID: 13748 Updated by: mfischer Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Program Execution Operating System: Windows 2000 SP2 w/IIS5.0 PHP Version: 4.0.6 New Comment: Submitted twice - bogus. - Markus Whats up today guys? Did you all forgot that reloading the page also submits form data again? Why isn't php.net redirecting after a POST? That's a common solution, and also makes sure you can have a logic-only php script, since you're redirecting to a page-with-layout. By means of a get var (or coockies) you can pass on the submission result, i.e. succesfull or not. This way you effectively prevent multiple postings. --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13756 Updated: exponential ** operator
ID: 13756 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: n/a PHP Version: 4.0.6 New Comment: I proposed that earlier (along with ^^) [ZendEnginge ML, june 27th july 3rd]. Anyway, I think it should be added, there is simply no power operator now, and pow() is both a bit bugly and overloaded (both ^^ and ** at the same time). Previous Comments: [2001-10-19 11:24:28] [EMAIL PROTECTED] ** is Pascal, not C [2001-10-19 10:36:03] [EMAIL PROTECTED] It would be nice to have an exponential operator. ** would be a logical choice, just like in C. Example: echo 2**3; // prints 8 I know we have pow(), but an operator for this would be nice... Edit this bug report at http://bugs.php.net/?id=13756edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12590 Updated: hex const (0xABCDEF01) parsing error
ID: 12590 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.0.5 New Comment: On most platforms (including i386), PHP does not support integers of 2**31 (0x80 00 00 00) and higher. See the manual on integers. So the result of the second expression is unknown. (0x80FF is converted to float because of integer-overflow, and you cannot use bitwise fucntions on floats) Previous Comments: [2001-10-18 15:45:55] [EMAIL PROTECTED] What would you expect to get? On my machine, it prints out 255 twice. [2001-08-06 07:35:58] [EMAIL PROTECTED] Looks like there's some trouble with parsing big hex consts (those with sign bit set). Try this: ... echo (0x7FFF00FF 0x); //echoes 255 echo (0x80FF 0x); //echoes 0!!! ... 0x80FF apparently is mis-parsed. Edit this bug report at http://bugs.php.net/?id=12590edit=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] Fw: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c
Resent. The discussion isn't closed yet, and this is important, since it
will be already in 4.1.0
--Jeroen
- Original Message -
From: Jeroen van Wolffelaar [EMAIL PROTECTED]
To: Andi Gutmans [EMAIL PROTECTED]
Cc: PHP cvs [EMAIL PROTECTED]
Sent: Wednesday, October 10, 2001 8:46 PM
Subject: Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c
Stig,
Can we please keep these function names consistent with the PHP way and
not
with Perl? We decided a long time ago to use significant function names,
i.e., version_equals(). Also, do we really need all of those?
Why not simply return -1, 0, 1, just like any comparator?
The idea of 'comparator' is already in PHP in some places. Then you don't
have an additional parameter, and only 1 function.
version_compare() would be the best name then.
--Jeroen
Andi
At 10:32 AM 10/10/2001 +, Stig Bakken wrote:
ssb Wed Oct 10 06:32:17 2001 EDT
Modified files:
/php4/ext/standard basic_functions.c
Log:
* added function entries for version_{lt,le,gt,ge,eq}
Index: php4/ext/standard/basic_functions.c
diff -u php4/ext/standard/basic_functions.c:1.405
php4/ext/standard/basic_functions.c:1.406
--- php4/ext/standard/basic_functions.c:1.405 Sun Oct 7 14:34:44
2001
+++ php4/ext/standard/basic_functions.c Wed Oct 10 06:32:16 2001
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: basic_functions.c,v 1.405 2001/10/07 18:34:44 derick Exp $ */
+/* $Id: basic_functions.c,v 1.406 2001/10/10 10:32:16 ssb Exp $ */
#include php.h
#include php_main.h
@@ -792,6 +792,11 @@
/* functions from versioning.c */
PHP_FE(version_compare,
NULL)
+PHP_FE(version_lt,
NULL)
+PHP_FE(version_le,
NULL)
+PHP_FE(version_gt,
NULL)
+PHP_FE(version_ge,
NULL)
+PHP_FE(version_eq,
NULL)
{NULL, NULL, NULL}
};
--
PHP CVS 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] Fw: heredoc: change of behavoiur?
Resent due to lack of feedback.
- Original Message -
From: [EMAIL PROTECTED]
Newsgroups: php.dev
Sent: Wednesday, October 10, 2001 5:28 PM
Subject: heredoc: change of behavoiur?
Currently, heredoc as a bit of strange behaviour in syntax of terminating
it.
I think it's a good idea to be a bit looser. It will make it more
consistent, and allows inline use of heredoc.
For BC: I really think that's no problem, but in rare cases it could lead
to
problems. I don't know yet wether BC alone would be showstopper for this
patch.
On the way this patch also solves the bug that mac-newlines are not
understood (didn't see a bug report yet, but that's probably because not
much people use the mac...)
if there are other reasons to hold to the current syntax, please let me
know.
(see also: bug 13610)
Patch available here:
http://www.A-Eskwadraat.nl/~jeroen/php/looser_heredoc.diff
which changes behaviour to:
A heredoc is considered closed when the heredoc identifier appears
directly
after a newline. Remaining characters are allowed, provided they are
invalid
identifyer characters.
Example:
?php
mail('[EMAIL PROTECTED]', 'heredoc test', TEXT
Hello Jeroen,
Greets!
TEXT, 'Cc: [EMAIL PROTECTED]');
?
And this works:
?php
echo HEREDOC
bla
HEREDOCUMENTATION;
HEREDOC; // here the heredoc ends
?
But this doesn't:
?php
echo HEREDOC
bla
HEREDOC UMENTATION;
HEREDOC;
?
for the same reason as this is:
echo bla UMENTATION;
causes a parse error.
--
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] Shuffle() - change of algorithm needed (also relevant for array_rand())
Resent due to lack of feedback. Objections against me changing it to the behaviour I described below? --Jeroen - Original Message - From: Jeroen van Wolffelaar [EMAIL PROTECTED] To: PHP Developers Mailing List [EMAIL PROTECTED] Sent: Monday, October 15, 2001 9:45 PM Subject: Re: Bug #7045 Updated: Shuffle() does behave correctly ID: 7045 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Analyzed Status: Open Bug Type: Arrays related Operating System: Linux RH 6 and 7 PHP Version: 4.0.1pl2 New Comment: snip [2000-10-30 10:07:36] [EMAIL PROTECTED] This is probably the property of sort algorithm used in shuffle. Whoever wrote it, please take attention! The algorithm is a mergesort with a random comparer. That's not going to give a well shuffle. There are a few alternatives. First, it's important to know wether one can random-access the array. IIRC, that's not possible. So the straight forward O(n) algorithm won't work directly (well, it'll work, but definitely not in O(n)). It can be easily made to work by simply indexing the array first (from outside). It's straight forward, and thus quite easy to assure that it's correct, and quite easy to implement too. The external indexing step is also O(n), so speed isn't dramatically affected. Note that this algortihm is a lot faster than the current one. Mergesort is O(nlogn), with more memory usage, and quite heavier draw on the random number generator. NB: also the array_rand() function has a bad algorithm. The same algorithm could and should be used, it also elimintates the use of shuffle inside array_rand(). --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Fw: [PATCH] Fix for inconsistent float-int converting
Resent, due to lack of feedback from my side ;) Andi replied: Why is it more correct to convert it to min/max values? I can't think of a case where this would make more sense to the developer. Also, there is a reason for the cast to unsigned int if the value is bigger that LONG_MAX. I think it makes sense. If a float is out-of-range, it can usually not be mod'd by 2**32, due to the nature of floats. Therefore, the only consistent way would be going to the nearest integer possible. Okay, because on most systems floats happen to be more precise than int's, you _can_ mod them by 2**32, but there is a quite significant possibility of having rounding errors. You cannot do integer-precision with floats. And it's inconsistent too, PHP int's are ranging from -2**31 to (2**31)-1, there is no such thing as unsigned integers. So why convert the float 3e9 to something way below zero? Additionally, a notice is a good idea here, just like what happens on division by zero: the most natural result is returned, and a notice is issued. --Jeroen - Original Message - From: Jeroen van Wolffelaar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 02, 2001 2:39 AM Subject: [PATCH] Fix for inconsistent float-int converting When a too-large float is converted to integer, it happens in a quite random way. When float is out of range, PHP should stick to the min resp. max values of integer. This patch will achieve this, I tested it succesfully. --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen double.diff -- 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] Random
(you'd already have expected this, i guess...) I still have hardly no feedback on proposal 3b of random change: http://www.a-eskwadraat.nl/~jeroen/rand/ The main issue - inconsistent and duplicate functions for random, no way to explicitly and portably get reproducable results - isn't solved by bugfixes that have been applied now. Note that it's now __not a redesign__, but new - better IMO - interface to random functions. No BC-problems. --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13740 Updated: Call to undefined function: dbmopen()
ID: 13740 Updated by: jeroen Reported By: [EMAIL PROTECTED], Old Status: Open Status: Bogus Bug Type: Unknown/Other Function Operating System: Free BSD PHP Version: 4.0.6 New Comment: You probably didn't compile with dbm support. Ask support questions on www.php.net/support.php (php-install in your case), this is _not_ a support forum. Previous Comments: [2001-10-18 18:18:36] [EMAIL PROTECTED], I'm new to php. Got the following error when trying to open a DBM: Installation of PHP was with the defaults, is there some additional SW that will allow DBM? Fatal error: Call to undefined function: dbmopen() //open a DBM database; create if it doesn't exist $fn = /qes/IP4700 # $dbh = dbmopen( $UserDefinedTSdir, c ) or die ( Couldn't open DBM ); $dbh = dbmopen( $fn, c ) or die ( Couldn't open DBM ); dbmclose ($dbh); Edit this bug report at http://bugs.php.net/?id=13740edit=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]
Fw: [PHP-DEV] Bug #13740 Updated: Call to undefined function: dbmopen()
I really don't know, forwarding to php-dev... That bug hasn't yet been looked after, it contains a reproducing script (dba-related). --Jeroen - Original Message - From: Pierre-Alain Joye [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 19, 2001 12:40 AM Subject: Re: [PHP-DEV] Bug #13740 Updated: Call to undefined function: dbmopen() Hello, do you know if there is still someone on the gdbm/dba wrapper part ? I got a bug on my system (Bug #13660). best regards, pa -- 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] Fw: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c
version_compare() with two args returns -1 / 0 / 1 today, if you want to
use it that way please do. I think the third arg is useful, and it's
not exactly bothering people who don't need it. I consider this
discussion as closed.
Hm, I did miss something :(.
I consider the discussion closed too, it just comes down to proper
documentation now.
Sorry
--Jeroen
(Just for the record: version_compare is the only function now,
version_lt friends are gone.)
That I didn't miss...
- Stig
Jeroen van Wolffelaar wrote:
Resent. The discussion isn't closed yet, and this is important, since it
will be already in 4.1.0
--Jeroen
- Original Message -
From: Jeroen van Wolffelaar [EMAIL PROTECTED]
To: Andi Gutmans [EMAIL PROTECTED]
Cc: PHP cvs [EMAIL PROTECTED]
Sent: Wednesday, October 10, 2001 8:46 PM
Subject: Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c
Stig,
Can we please keep these function names consistent with the PHP way
and
not
with Perl? We decided a long time ago to use significant function
names,
i.e., version_equals(). Also, do we really need all of those?
Why not simply return -1, 0, 1, just like any comparator?
The idea of 'comparator' is already in PHP in some places. Then you
don't
have an additional parameter, and only 1 function.
version_compare() would be the best name then.
--Jeroen
Andi
At 10:32 AM 10/10/2001 +, Stig Bakken wrote:
ssb Wed Oct 10 06:32:17 2001 EDT
Modified files:
/php4/ext/standard basic_functions.c
Log:
* added function entries for version_{lt,le,gt,ge,eq}
Index: php4/ext/standard/basic_functions.c
diff -u php4/ext/standard/basic_functions.c:1.405
php4/ext/standard/basic_functions.c:1.406
--- php4/ext/standard/basic_functions.c:1.405 Sun Oct 7 14:34:44
2001
+++ php4/ext/standard/basic_functions.c Wed Oct 10 06:32:16 2001
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: basic_functions.c,v 1.405 2001/10/07 18:34:44 derick Exp $
*/
+/* $Id: basic_functions.c,v 1.406 2001/10/10 10:32:16 ssb Exp $ */
#include php.h
#include php_main.h
@@ -792,6 +792,11 @@
/* functions from versioning.c */
PHP_FE(version_compare,
NULL)
+PHP_FE(version_lt,
NULL)
+PHP_FE(version_le,
NULL)
+PHP_FE(version_gt,
NULL)
+PHP_FE(version_ge,
NULL)
+PHP_FE(version_eq,
NULL)
{NULL, NULL, NULL}
};
--
PHP CVS 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]
Re: [PHP-DEV] Fw: [PATCH] Fix for inconsistent float-int converting
On Fri, 19 Oct 2001, Stig S. Bakken wrote: In cases like these I think PHP should do whatever C does. There's no point in trying to be clever when casts overflow. In C, when you doe int i;, i will contain random data. In PHP, a variable will always be cleared (to null). In C, when you cast a out-of-range-float, I doubt wether it's defined. Furthermore, PHP is not C, so I see no reason to follow C just like that. What do you expect from trying to store a too big float in an integer? I expect an error, and the nearest valid result. I really see no logic in the current behavior, only that it makes a limited amount of unsigned-int faking possible. But floats are floats, that's not going well all the time (see the numerous bugreports on this kind of gotcha's). So also for this reason I believe there should be no such wrapping behaviour, as it might lead people to think unsigned ints are supported, resulting in very strange things. Especially the E_NOTICE when this happens will help a lot of people IMO. In the case of casting larger integers into smallers, it's differnt because you're talking about _intgers_ then, and not floats. --Jeroen - Stig Jeroen van Wolffelaar wrote: Resent, due to lack of feedback from my side ;) Andi replied: Why is it more correct to convert it to min/max values? I can't think of a case where this would make more sense to the developer. Also, there is a reason for the cast to unsigned int if the value is bigger that LONG_MAX. I think it makes sense. If a float is out-of-range, it can usually not be mod'd by 2**32, due to the nature of floats. Therefore, the only consistent way would be going to the nearest integer possible. Okay, because on most systems floats happen to be more precise than int's, you _can_ mod them by 2**32, but there is a quite significant possibility of having rounding errors. You cannot do integer-precision with floats. And it's inconsistent too, PHP int's are ranging from -2**31 to (2**31)-1, there is no such thing as unsigned integers. So why convert the float 3e9 to something way below zero? Additionally, a notice is a good idea here, just like what happens on division by zero: the most natural result is returned, and a notice is issued. --Jeroen - Original Message - From: Jeroen van Wolffelaar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 02, 2001 2:39 AM Subject: [PATCH] Fix for inconsistent float-int converting When a too-large float is converted to integer, it happens in a quite random way. When float is out of range, PHP should stick to the min resp. max values of integer. This patch will achieve this, I tested it succesfully. --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen Name: double.diff double.diffType: unspecified type (application/octet-stream) Encoding: quoted-printable -- 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] Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13550 Updated: intval() does not round off doubles correctly
ID: 13550 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: *Programming Data Structures Operating System: Linux 2.2.18 PHP Version: 4.0.6 New Comment: No, floating point numbers are ALWAYS inprecise, and you shouldn't trust on their exact values. See the warning on http://www.php.net/manual/en/language.types.float.php The problem is that $scaled is 877.99 or something, and because of the precision setting in php.ini it is printed as 878, but when using (int) cast, or intval(), it will be rounded down (or twowards zero, don't reacall). By the way, pow(int,int) will yield integer values when possible since 4.0.7, which nukes one possible source of floating point problems (unless you use 10.0 of course, but that doesn't make sense in PHP) BTW: this is a FAQ, will add an entry. Previous Comments: [2001-10-05 08:35:55] [EMAIL PROTECTED] The bug is real. Try it on the mentioned OS with glibc version mentioned in the report to see it. [2001-10-05 08:30:42] [EMAIL PROTECTED] Except that it doesn't, here and in many other users machines it prints: int(2) float(100) string(4) 8.78 float(8.78) float(878) int(877) int(878) glibc rpm version is 2.2-7. [2001-10-05 03:58:28] [EMAIL PROTECTED] Could you be a little less cryptic please? I would expect this to print: int 2 float 100 string '8.78' float 8.78 float 878 int 878 int 878 Which is exactly what I am seeing. $scaled = 8.78 * 100.0 which gives a double value of 878.00 therefore round(878.00) would be 878 and intval(878) is 878. What exactly are you expecting to be different here? [2001-10-04 19:08:52] [EMAIL PROTECTED] It seems that intval does not round off double numbers like the function that prints those numbers. Try this script to see the problem. ? $decimal_places=2; $decimal_factor=pow(10.0,$decimal_places); $value='8.78'; $double=doubleval($value); $scaled=$double*$decimal_factor; $integer=intval($scaled); $round=intval(round($scaled)); var_dump($decimal_places,$decimal_factor,$value,$double,$scaled,$integer,$round); ? Edit this bug report at http://bugs.php.net/?id=13550edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13567 Updated: array_search does not return FALSE as documented, if no entry was found
ID: 13567
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Assigned
Status: Closed
Bug Type: Arrays related
Operating System: Linux 2.2.19
PHP Version: 4.0.5
Assigned To: jeroen
New Comment:
Fixed in CVS, will be in 4.0.8, and maybe in 4.0.7
(what's the policy on this kind of bugfixes?)
Previous Comments:
[2001-10-05 16:05:26] [EMAIL PROTECTED]
Use var_dump to check what's actually returned.
NULL is returned, confirmed with latest CVS.
Assigning to myself
[2001-10-05 14:50:57] [EMAIL PROTECTED]
script to reproduce the error quickly:
// won't produce output, is not boolean FALSE
if (array_search ('a', array ('b')) === FALSE)
echo 'is boolean FALSE';
// won't produce output, is not of type boolean
if (is_bool (array_search ('a', array ('b'
echo 'is boolean';
Edit this bug report at http://bugs.php.net/?id=13567edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13550 Updated: intval() does not round off doubles correctly
ID: 13550 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: *Programming Data Structures Operating System: Linux 2.2.18 PHP Version: 4.0.6 New Comment: Basically the bug is that in PHP: intval($double)!=intval(round($double)) converting to integer will round DOWN, while rounding first rounds towards the nearst integer. intval($float) and intval(floor($float)) should be the same for nonnegative $float's, but in the case of round that's not true. So not a bug Previous Comments: [2001-10-05 16:40:50] [EMAIL PROTECTED] I don't think you are understanding the problem. Basically the bug is that in PHP: intval($double)!=intval(round($double)) round($double) is still a floating point number. The problem is that currently in PHP the intval() floating point rounding rule is not the same as round() rule. This is a real PHP bug that needs to be fixed, because if: echo $double; prints the same as echo round($double); then echo intval($double); should print the same as echo intval(round($double)); [2001-10-05 15:56:41] [EMAIL PROTECTED] No, floating point numbers are ALWAYS inprecise, and you shouldn't trust on their exact values. See the warning on http://www.php.net/manual/en/language.types.float.php The problem is that $scaled is 877.99 or something, and because of the precision setting in php.ini it is printed as 878, but when using (int) cast, or intval(), it will be rounded down (or twowards zero, don't reacall). By the way, pow(int,int) will yield integer values when possible since 4.0.7, which nukes one possible source of floating point problems (unless you use 10.0 of course, but that doesn't make sense in PHP) BTW: this is a FAQ, will add an entry. [2001-10-05 08:35:55] [EMAIL PROTECTED] The bug is real. Try it on the mentioned OS with glibc version mentioned in the report to see it. [2001-10-05 08:30:42] [EMAIL PROTECTED] Except that it doesn't, here and in many other users machines it prints: int(2) float(100) string(4) 8.78 float(8.78) float(878) int(877) int(878) glibc rpm version is 2.2-7. [2001-10-05 03:58:28] [EMAIL PROTECTED] Could you be a little less cryptic please? I would expect this to print: int 2 float 100 string '8.78' float 8.78 float 878 int 878 int 878 Which is exactly what I am seeing. $scaled = 8.78 * 100.0 which gives a double value of 878.00 therefore round(878.00) would be 878 and intval(878) is 878. What exactly are you expecting to be different here? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=13550 Edit this bug report at http://bugs.php.net/?id=13550edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13550 Updated: intval() does not round off doubles correctly
ID: 13550 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *Programming Data Structures Operating System: Linux 2.2.18 PHP Version: 4.0.6 New Comment: quote This is a real PHP bug that needs to be fixed, because if: [1]echo $double; prints the same as [2]echo round($double); then [3]echo intval($double); should print the same as [4]echo intval(round($double)); /quote [1] and [2] _print_ the same, but they aren't. It's because of the precision setting in php.ini (14 significant numbers, IIRC) This is inherently to floating point numbers. Simply don't trust them to the last digit. Previous Comments: [2001-10-05 16:45:13] [EMAIL PROTECTED] Basically the bug is that in PHP: intval($double)!=intval(round($double)) converting to integer will round DOWN, while rounding first rounds towards the nearst integer. intval($float) and intval(floor($float)) should be the same for nonnegative $float's, but in the case of round that's not true. So not a bug [2001-10-05 16:40:50] [EMAIL PROTECTED] I don't think you are understanding the problem. Basically the bug is that in PHP: intval($double)!=intval(round($double)) round($double) is still a floating point number. The problem is that currently in PHP the intval() floating point rounding rule is not the same as round() rule. This is a real PHP bug that needs to be fixed, because if: echo $double; prints the same as echo round($double); then echo intval($double); should print the same as echo intval(round($double)); [2001-10-05 15:56:41] [EMAIL PROTECTED] No, floating point numbers are ALWAYS inprecise, and you shouldn't trust on their exact values. See the warning on http://www.php.net/manual/en/language.types.float.php The problem is that $scaled is 877.99 or something, and because of the precision setting in php.ini it is printed as 878, but when using (int) cast, or intval(), it will be rounded down (or twowards zero, don't reacall). By the way, pow(int,int) will yield integer values when possible since 4.0.7, which nukes one possible source of floating point problems (unless you use 10.0 of course, but that doesn't make sense in PHP) BTW: this is a FAQ, will add an entry. [2001-10-05 08:35:55] [EMAIL PROTECTED] The bug is real. Try it on the mentioned OS with glibc version mentioned in the report to see it. [2001-10-05 08:30:42] [EMAIL PROTECTED] Except that it doesn't, here and in many other users machines it prints: int(2) float(100) string(4) 8.78 float(8.78) float(878) int(877) int(878) glibc rpm version is 2.2-7. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=13550 Edit this bug report at http://bugs.php.net/?id=13550edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13550 Updated: intval() does not round off doubles correctly
ID: 13550 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *Programming Data Structures Operating System: Linux 2.2.18 PHP Version: 4.0.6 New Comment: Manuel ment that intval($double)==intval(round($double)) should be true in the context of $double == round($double) So his problem wasn't with mixing up round and intval, but his problem was that he didn't realize that (string)$double == (string)round($double) does not necessarily imply $double == round($double) (and which is not the case in this case, because the difference being to small to show up in the string representation) Previous Comments: [2001-10-05 17:00:03] [EMAIL PROTECTED] Ok, you could have stated this to begin with: intval($double)!=intval(round($double)) Where are you getting the idea that intval does a round()? intval(3.99) would be 3 round(3.99) would be 4 Therefore intval(round(3.99)) would be 4 and thus often intval($double) != intval(round($double)) [2001-10-05 16:54:14] [EMAIL PROTECTED] quote This is a real PHP bug that needs to be fixed, because if: [1]echo $double; prints the same as [2]echo round($double); then [3]echo intval($double); should print the same as [4]echo intval(round($double)); /quote [1] and [2] _print_ the same, but they aren't. It's because of the precision setting in php.ini (14 significant numbers, IIRC) This is inherently to floating point numbers. Simply don't trust them to the last digit. [2001-10-05 16:45:13] [EMAIL PROTECTED] Basically the bug is that in PHP: intval($double)!=intval(round($double)) converting to integer will round DOWN, while rounding first rounds towards the nearst integer. intval($float) and intval(floor($float)) should be the same for nonnegative $float's, but in the case of round that's not true. So not a bug [2001-10-05 16:40:50] [EMAIL PROTECTED] I don't think you are understanding the problem. Basically the bug is that in PHP: intval($double)!=intval(round($double)) round($double) is still a floating point number. The problem is that currently in PHP the intval() floating point rounding rule is not the same as round() rule. This is a real PHP bug that needs to be fixed, because if: echo $double; prints the same as echo round($double); then echo intval($double); should print the same as echo intval(round($double)); [2001-10-05 15:56:41] [EMAIL PROTECTED] No, floating point numbers are ALWAYS inprecise, and you shouldn't trust on their exact values. See the warning on http://www.php.net/manual/en/language.types.float.php The problem is that $scaled is 877.99 or something, and because of the precision setting in php.ini it is printed as 878, but when using (int) cast, or intval(), it will be rounded down (or twowards zero, don't reacall). By the way, pow(int,int) will yield integer values when possible since 4.0.7, which nukes one possible source of floating point problems (unless you use 10.0 of course, but that doesn't make sense in PHP) BTW: this is a FAQ, will add an entry. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=13550 Edit this bug report at http://bugs.php.net/?id=13550edit=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] zend_compare co
Can you trust on the compare functions to return either -1, 0 or 1? I don't think so... but since that assumption is made in various locations in PHP4, it maybe is true? Similar question for zend booleans, can you trust the lval to be either 0 or 1, or not? --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13530 Updated: IMAP will not disable
ID: 13530 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *Compile Issues Operating System: Mandrake Linux 7.0 PHP Version: 4.0.6 New Comment: Please check that it's the right php.ini that is used (make an intentional syntax error and see wether PHP complains). also grep through your /etc/apache dir for imap, the reference could be in there. If that doesn't solve it, ask your support question on www.php.net/support.php, because this is very likely not a bug. Previous Comments: [2001-10-03 12:05:55] [EMAIL PROTECTED] Read my original posting - imap.so is NOT in my php.ini file. This is not the source of the problem. [2001-10-03 11:21:30] [EMAIL PROTECTED] A extension=...imap.so line is still in your php.ini Please go to www.php.net/support.php for support questions. [2001-10-03 11:17:10] [EMAIL PROTECTED] I am attempting to upgrade my PHP installation to 4.06. I configured php with the following line: ./configure --with-apxs=/usr/sbin/apxs --with-zlib --with-regex=system --enable-trans-sid --disable-debug --with-mysql The configure script, make, and make install all appear to run normally. However, when I restart Apache (1.3.9-Mandrake rpms), I get the following message: Syntax error on line 74 of /etc/httpd/httpd.conf: Cannot load /usr/lib/apache/libphp4.so into server: /usr/lib/libimap.so.4: undefined symbol:mm_dlog As you will notice from my configure line, I haven't included imap support, so why is an imap library killing my installation? I have checked my php.ini, and there is no reference to the imap.so, so it's not an extension that it's trying to load. I've even explicitly disabled imap in the configure line - same result. What's going on? For your further information, my system has imap libraries from a courier-imap/sqwebmail installation, not the uw imap, which is why I have not tried to include imap in my php. Edit this bug report at http://bugs.php.net/?id=13530edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13524 Updated: session_unset() with no registered vars causes segfault w/save_handler=user
ID: 13524
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Closed
Status: Open
Bug Type: Session related
Operating System: linux 2.2.19 redhat
PHP Version: 4.0.5
New Comment:
Reopening. PHP should never segfault.
Tried to reproduce with current CVS, but that didn't work.
Can you please try to reproduce it with a snapshot from http://snaps.php.net?
Previous Comments:
[2001-10-02 20:31:48] [EMAIL PROTECTED]
added the NECESSARY returns on all the handler functions and now it appears to work
fine.
sorry for the inconvenience...
[2001-10-02 20:09:55] [EMAIL PROTECTED]
Your write, destroy and gc functions need to return true on success. Shouldn't cause
a segfault of course, but try fixing that and also try a recent version of PHP.
[2001-10-02 20:05:06] [EMAIL PROTECTED]
when using session_unset() with no registered vars in the session, i get an apache
segfault. i only experience this when using my own session handlers
(sessions.save_handler = user in php.ini). when using files, i don't get segfault.
here are scripts i used to cause this error:
---sessions.lib---
?php
// $Id$
/*
* session table schema
*
* create table SOLR_SESSIONS (
* session_id char(32) not null,
* session_datatext not null,
* session_expiration int(11) unsigned not null,
* primary key (session_id));
*
*/
// PEAR db abstraction
require_once(DB.php);
function on_session_start($save_path, $session_name) {
global $dbh;
return TRUE;
// does nothing since we already have a db connection
}
function on_session_end() {
global $dbh;
return TRUE;
// does nothing
}
function on_session_read($key) {
global $dbh;
$sql = SELECT session_data FROM SOLR_SESSIONS WHERE session_id = '$key' and
session_expiration UNIX_TIMESTAMP(NOW());
$result = $dbh-query($sql);
if(DB::isError($result)) {
return ;
}
$row = $result-fetchRow(DB_FETCHMODE_ASSOC);
return $row[session_data];
}
function on_session_write($key, $val) {
global $dbh;
$insert_sql = INSERT INTO SOLR_SESSIONS values ('$key', '$val',
UNIX_TIMESTAMP()+3600);
$update_sql = UPDATE SOLR_SESSIONS SET session_data = '$val',
session_expiration = UNIX_TIMESTAMP()+3600, WHERE session_id = '$key';
if(DB::isError($dbh-query($insert_sql))) {
$dbh-query($update_sql);
}
}
function on_session_destroy($key) {
global $dbh;
$sql = DELETE FROM SOLR_SESSIONS WHERE session_id = '$key';
$dbh-query($sql);
}
function on_session_gc($max_lifetime) {
global $dbh;
$sql = DELETE FROM SOLR_SESSIONS WHERE session_expiration
UNIX_TIMESTAMP(NOW());
$dbh-query($sql);
}
?
---testsessions.php---
?php
// testsessions.php
/*
* session table schema
*
* create table SOLR_SESSIONS (
* session_id char(32) not null,
* session_datatext not null,
* session_expiration int(11) unsigned not null,
* primary key (session_id));
*
*/
error_reporting(E_ALL);
require_once(DB.php);
require_once(libs/sessions.lib);
session_set_save_handler(on_session_start, on_session_end,
on_session_read, on_session_write,
on_session_destroy,
on_session_gc);
$dbh = DB::connect(mysql://solr:ziggurat-keep@localhost/SOLR);
if(DB::isError($dbh)) {
die($dbh-get_error());
}
session_start();
if(session_is_registered(someval)) {
echo someval=.$someval.br\n;
} else {
// if you comment session_unset(), it works fine.
session_unset();
session_destroy();
//header(Location: testsessions2.php);
echo someval not registeredbr\n;
echo a href=\testsessions2.php\go here to register someval/a\n;
}
?
---testsessions2.php---
?php
// testsessions2.php
error_reporting(E_ALL);
require_once(DB.php);
require_once(libs/sessions.lib);
session_set_save_handler(on_session_start, on_session_end,
on_session_read, on_session_write,
on_session_destroy,
on_session_gc);
$dbh = DB::connect(mysql://solr:ziggurat-keep@localhost/SOLR);
if(DB::isError($dbh)) {
die($dbh
[PHP-DEV] Bug #13530 Updated: IMAP will not disable
ID: 13530 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: *Compile Issues Operating System: Mandrake Linux 7.0 PHP Version: 4.0.6 New Comment: A extension=...imap.so line is still in your php.ini Please go to www.php.net/support.php for support questions. Previous Comments: [2001-10-03 11:17:10] [EMAIL PROTECTED] I am attempting to upgrade my PHP installation to 4.06. I configured php with the following line: ./configure --with-apxs=/usr/sbin/apxs --with-zlib --with-regex=system --enable-trans-sid --disable-debug --with-mysql The configure script, make, and make install all appear to run normally. However, when I restart Apache (1.3.9-Mandrake rpms), I get the following message: Syntax error on line 74 of /etc/httpd/httpd.conf: Cannot load /usr/lib/apache/libphp4.so into server: /usr/lib/libimap.so.4: undefined symbol:mm_dlog As you will notice from my configure line, I haven't included imap support, so why is an imap library killing my installation? I have checked my php.ini, and there is no reference to the imap.so, so it's not an extension that it's trying to load. I've even explicitly disabled imap in the configure line - same result. What's going on? For your further information, my system has imap libraries from a courier-imap/sqwebmail installation, not the uw imap, which is why I have not tried to include imap in my php. Edit this bug report at http://bugs.php.net/?id=13530edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13520 Updated: Wrong handling of the escape characters.
ID: 13520 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Output Control Operating System: PHP Version: 4.0.6 New Comment: And you're mixing up a PHP enviroment and a HTML enviroment. They both have their own rules for escaping. See the HTML specs for how HTML handles things Previous Comments: [2001-10-02 16:24:25] [EMAIL PROTECTED] This is not a bug. There is a configuration setting that controls this behavior. Review the configuration section of the manual (http://www.php.net/manual/en/configuration.php) Specifically, read the entries on them magic_quotes directives. [2001-10-02 16:06:41] [EMAIL PROTECTED] In a html: a href=test.php?str=some'thingtest/a And the test.php: ? echo $str; ? I used the win32 binary version of the php. In the link I put the some'thing into the str variable whivh will pass to the script if i click on the Testlink. I read in the manual the ' \ are special character, and I must escape them with a \. Ok, I didn't used the \ before the ' in the something text, so I think the normal is that I get some error message... But no: thw script will output the some\'thing text... which are funy because if I put the $str into a database (with a mysql_query) it will contain the original text: some'thing. And if I use the \ in my link (like this: test.php?str=some\'thing) then the script will output the some\\\'thing... But I think it must output the some'thing because I used the \ before the '. So, could be this a bug? I think so... Edit this bug report at http://bugs.php.net/?id=13520edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12596 Updated: Definition of array using constants in array doesn't work
ID: 12596
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Bogus
Status: Suspended
Bug Type: Class/Object related
Operating System: Linux
PHP Version: 4.0.5
New Comment:
It _is_ strange that no parse error is given. I think it should.
So IMO the bug is that it seems to work a bit, but doesn't. Either support this, or
give parse error.
I see no reason to not support a random expression though... that expression-opcodes
should internally be moved to class initialization. Since PHP 4 doesn't have a real
constructor, this won't be realizable until ZE 2 I think.
Status-Suspended
Previous Comments:
[2001-10-02 18:34:02] [EMAIL PROTECTED]
Not a bug - Bogus.
[2001-08-06 15:27:23] [EMAIL PROTECTED]
This isn't supposed to work (class-var initing is not allowed for non-scalar (for
example array) values).
It is funny that it turns out to work this way, a parse-error would be better IMO.
But it is not a bug, changing status to feedback.
It is in the manual somewhere that this isn't allowed, try language - classes and
object
[2001-08-06 09:41:56] [EMAIL PROTECTED]
The following piece of code doesn't work:
?
define ('A', 20);
class B
{
var $a = array(A = 10);
}
$b = new B();
var_dump($b);
?
It produces:
object(b)(1) {
[a]=
array(1) {
[A]=
int(10)
}
}
which is unexpected (at least for me).
Edit this bug report at http://bugs.php.net/?id=12596edit=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: Minor addition to http://php.net/anoncvs.php?
Does anyone object to me modifying the anoncvs.php webpage to include the following note? Does anyone have anything to add - Jeroen? :) There's a typo in it, but that's not what you meant :-) I wouldn't name that SuSE thing, it's way to specific for indicating that something DOESN'T work. I'd just name the combination which _does_ work. I've put a suggestion below, but it's just that -- a suggestion. -- warning para Certain combinations of autoconf, automake and libtool may cause the buildconf script to fail. /para para Under SuSE 7.1 (Linux kernal 2.2.18 i686) autoconf version 2.13, kernal-kernel automake version 1.4 (ok) and libtool version 1.4.2 are suspected not to work. /para I'd say skip the para up here, and in stead: para There seem to be problems with libtool 1.4.2, it is suggested that you use libtool 1.4, along with the most current autoconf and automake. Make sure you install there three tools in the same directory. The following combination is known to work: autoconf 2.52, automake 1.5 and libtool 1.4. /para Feel free to rephrase... para libtool 1.4.2 may not work with any current (as of 2001/09/30) versions of autoconf and automake. /para /warning --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug in autoconf report
Hi Jeroen, Did you ever get the problem sorted out? Has anyone encountered the same difficulty? I installed brand new autoconf, automake and libtool into my $HOME. That solved the problem. However, I still don't know what the problem was, probably there were some library files not well installed. Anyway, I'm not the administrator of that computer, so I couldn't do much more than bugging sysop and/or install those tools in my homedir. The former one didn't help, the latter one did. The server I tried on was Debian, and in my original mail you can find the versions I had at that time. Currently, it is: buildconf: checking installation... buildconf: autoconf version 2.52 (ok) buildconf: automake version 1.5 (ok) buildconf: libtool version 1.4 (ok) -- on purpose, read somewhere that some version was giving trouble, so I played on safe. rebuilding Makefile templates --Jeroen I just encountered the same issue in almost the same circumstances. In my case, automake and libtool both live in /usr/bin. % cd php4 % ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) buildconf: libtool version 1.4.2 (ok) rebuilding Makefile templates rebuilding configure autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF configure.in:162:AC_MSG_RESULT([$PHP_SAPI]) configure.in:182:AC_MSG_RESULT([$php_cv_cc_dashr]) [output truncated for brevity's sake] I am updating all of my Autotools - will try again when that is done. --zak On September 25, 2001 11:53 am, Jeroen van Wolffelaar wrote: On Tue, 25 Sep 2001, Jeroen van Wolffelaar wrote: snip Note: after I solved that warning about automake libtool not being in the same dir, the error remainded the same. (I copied the automake executable to the same dir as the libtool executable) Ok, but it's still a problem with your build tools, it works fine here. You re-ran buildconf I guess? Yes, retrieving the whole CVS again takes quite some time again... what's the command to clean all files that are not from CVS, so that I've got a really clean tree again? make clean / make distclean? (But they don't yet work before you run configure...) So you think libtool is mal-installed? Could be possible... Derick --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: zip ext compile problem
Fixed - Original Message - From: Holger Schopohl [EMAIL PROTECTED] Newsgroups: php.dev To: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 10:51 AM Subject: zip ext compile problem Hi, in the current cvs tree the zip extension have problems to compile with zziplib 0.10.27 zip.c: In function `zif_zip_entry_open': zip.c:265: parse error before `else' zip.c: At top level: zip.c:266: parse error before `return' zip.c: In function `zif_zip_entry_read': zip.c:290: parse error before `else' zip.c:291: `__l' undeclared (first use in this function) zip.c:291: (Each undeclared identifier is reported only once zip.c:291: for each function it appears in.) zip.c:291: `__s' undeclared (first use in this function) zip.c: At top level: zip.c:291: parse error before `return' Regards, Holger -- 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 autoconf report
[jeroen@richard]~/scratch/tmp/php4-cvs ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4-p4 (ok) buildconf: libtool version 1.4 (ok) WARNING: automake and libtool are installed in different directories. This may cause aclocal to fail. continuing anyway rebuilding Makefile templates automake: configure.in: installing `Zend/ylwrap' rebuilding configure autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF configure.in:162:AC_MSG_RESULT([$PHP_SAPI]) configure.in:182:AC_MSG_RESULT([$php_cv_cc_dashr]) configure.in:192: AC_MSG_RESULT([$php_cv_cc_rpath]) configure.in:220: AC_DEFINE(HAVE_LIBSOCKET,1,[ ]) ], [ configure.in:238: AC_DEFINE(HAVE_LIBNSL,1,[ ]) ],[ configure.in:241: AC_DEFINE(HAVE_LIBNSL,1,[ ]) ], []) configure.in:267: AC_DEFINE(HAVE_LIBSOCKET,1,[ ]) ], [ configure.in:270: AC_DEFINE(HAVE_LIBRESOLV,1,[ ]) configure.in:363: AC_DEFINE(HAVE_IPV6,1,[Whether you have IPv6 support]) configure.in:437: AC_DEFINE(HAVE_GETADDRINFO,1,[Define if you have the getaddrinfo function]) configure.in:463:dnl AC_MSG_RESULT([$ac_cv_type_in_addr_t]) configure.in:465: AC_DEFINE(in_addr_t, u_int, [ ]) configure.in:528: AC_DEFINE(PHP_SAFE_MODE,1,[ ]) configure.in:530: AC_DEFINE(PHP_SAFE_MODE,0,[ ]) configure.in:540: AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,/usr/local/php/bin, [ ]) configure.in:541: AC_MSG_RESULT([/usr/local/php/bin]) configure.in:543: AC_DEFINE_UNQUOTED(PHP_SAFE_MODE_EXEC_DIR,$withval, [ ]) configure.in:544: AC_MSG_RESULT([$withval]) configure.in:547: AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,/usr/local/php/bin, [ ]) configure.in:548: AC_MSG_RESULT([/usr/local/php/bin]) configure.in:551: AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,/usr/local/php/bin, [ ]) configure.in:552: AC_MSG_RESULT([/usr/local/php/bin]) configure.in:569: AC_DEFINE(PHP_SIGCHILD, 1, [ ]) configure.in:571: AC_DEFINE(PHP_SIGCHILD, 0, [ ]) configure.in:578: AC_DEFINE(MAGIC_QUOTES, 1, [ ]) configure.in:580: AC_DEFINE(MAGIC_QUOTES, 0, [ ]) configure.in:603: AC_DEFINE(DEFAULT_SHORT_OPEN_TAG,1,[ ]) configure.in:605: AC_DEFINE(DEFAULT_SHORT_OPEN_TAG,0,[ ]) configure.in:616:AC_DEFINE(HAVE_DMALLOC,1,[Whether you have dmalloc]) configure.in:629: AC_DEFINE(HAVE_PHP_STREAM, 1, [Whether to use php streams]) configure.in:635: AC_DEFINE(HAVE_CRYPT,1,[ ]) configure.in:655:AC_MSG_RESULT([$PHP_VERSIONING]) configure.in:704: AC_DEFINE(ZTS,1,[ ]) configure.in:817:AC_DEFINE_UNQUOTED(PHP_BUILD_DATE,$PHP_BUILD_DATE,[PHP build date]) configure.in:819:AC_DEFINE_UNQUOTED(PHP_UNAME,$PHP_UNAME,[uname -a output]) configure.in:821:AC_DEFINE_UNQUOTED(PHP_OS,$PHP_OS,[uname output]) configure.in:88:AC_MSG_RESULT([$1.$2 (ok)]) rebuilding acconfig.h rebuilding main/php_config.h.in [jeroen@richard]~/scratch/tmp/php4-cvs Note: after I solved that warning about automake libtool not being in the same dir, the error remainded the same. This is a fresh CVS of 3 minutes ago. When I run configure arterwards: ./configure snip Configuring Zend checking build system type... i686-pc-linux-gnu checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD-compatible nm... /usr/bin/nm -B updating cache ./config.cache ./ltconfig: ./ltconfig: No such file or directory configure: error: libtool configure failed (indeed, 'ltconfig' doesn't exist) Also note that I didn't ever succesfully build PHP directly from CVS - I didn't have libtool 1.4 till yesterday --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug in autoconf report
- Original Message - From: [EMAIL PROTECTED] To: Jeroen van Wolffelaar [EMAIL PROTECTED] Cc: PHP Development List [EMAIL PROTECTED] Sent: Tuesday, September 25, 2001 7:46 PM Subject: Re: [PHP-DEV] Bug in autoconf report On Tue, 25 Sep 2001, Jeroen van Wolffelaar wrote: [jeroen@richard]~/scratch/tmp/php4-cvs ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4-p4 (ok) buildconf: libtool version 1.4 (ok) WARNING: automake and libtool are installed in different directories. This may cause aclocal to fail. continuing anyway so don't do that... install them into the same dir. This causes the errors below probably. snip Note: after I solved that warning about automake libtool not being in the same dir, the error remainded the same. (I copied the automake executable to the same dir as the libtool executable) This is a fresh CVS of 3 minutes ago. When I run configure arterwards: ./configure snip Configuring Zend checking build system type... i686-pc-linux-gnu checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD-compatible nm... /usr/bin/nm -B updating cache ./config.cache ./ltconfig: ./ltconfig: No such file or directory configure: error: libtool configure failed (indeed, 'ltconfig' doesn't exist) Also note that I didn't ever succesfully build PHP directly from CVS - I didn't have libtool 1.4 till yesterday --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug in autoconf report
On Tue, 25 Sep 2001, Jeroen van Wolffelaar wrote: snip Note: after I solved that warning about automake libtool not being in the same dir, the error remainded the same. (I copied the automake executable to the same dir as the libtool executable) Ok, but it's still a problem with your build tools, it works fine here. You re-ran buildconf I guess? Yes, retrieving the whole CVS again takes quite some time again... what's the command to clean all files that are not from CVS, so that I've got a really clean tree again? make clean / make distclean? (But they don't yet work before you run configure...) So you think libtool is mal-installed? Could be possible... Derick --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Fw: Bumping PHP to support 8byteintegers
On Sun, 23 Sep 2001 [EMAIL PROTECTED] wrote: Hey, it's open source, go for it dude. Let us know. :-) I at least wanted to hear wether there are some principial contra's against this, because it would be a waste of time if it turned out that one wouldn't ever think of implementing this. And I didn't know wether this has been thought over before. A major point is of course that it would probably break ALL extensions, unless they use Z_LVAL() macro's all the time in stead of zval.value.lval... I'll see wether I can get it more or less running without too much work... My estimate is that the performance inpact will be not more than a few percents, probably lower. But it's an estimate! On the 32bit environments, 64bit integers are implemented as long long, unless you want to implement the 64bit manipulation routines yourself (yikes.) I didn't plan to implement it myself... yikes indeed. The question was wether all compilers on 32bit platforms DO have long long support at all, in other words: is it true that all compilers for which PHP needs to compile have a C-type which is 64bit (native or not)? --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #6662 Updated: array keys of type real not allowed?
ID: 6662
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 4.0.2
New Comment:
From the docs (by heart): in object initializers only constant scalar experssions are
allowed, no arrays, objects, or expressions, only simple int/float/etc.
That's incorrect thus? Should be 'only constant values', because arrays and 'new
Object()' are allowed? Or arrays only?
IMO, it should be the case, but I don't know wether it's supported in ZE1.
Previous Comments:
[2001-05-06 11:38:46] [EMAIL PROTECTED]
Fixed in the CVS - thanks for your report!
[2000-09-16 17:00:56] [EMAIL PROTECTED]
Float keys don't work, the variable gets converted to integer. This, however, doesn't
work with array initializers - this should be fixed.
[2000-09-11 22:06:25] [EMAIL PROTECTED]
It seems that array keys of type real are not allowed in class declaration:
class MyClass {
var $a = array( 1.5=1, 3.5=2, 7.5=5, 99=10);
...
}
Results in only one item 99=10 in array.
Above is accepted in PHP3.
Workaround:
var $a = array( '1.5'=1, '3.5'=2, '7.5'=5, '99'=10);
Edit this bug report at http://bugs.php.net/?id=6662edit=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: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV]Fw: Bumping PHP to support 8byte integers
On Mon, 24 Sep 2001, Markus Fischer wrote: Hm. You go and figure out and tell us all. :-) Btw, macros should _always_ be used. There is no no ever never a reason not to do so. *waiting for the patch* ;-) Ithink i'm going to try wether it works, and i'll commit my huge findreplace for the macro's... Unsubscribe from php-cvs while you still can ;-) (just kidding... I hope) Jeroen - Markus On Mon, Sep 24, 2001 at 09:13:35AM +0200, Jeroen van Wolffelaar wrote : On Sun, 23 Sep 2001 [EMAIL PROTECTED] wrote: Hey, it's open source, go for it dude. Let us know. :-) I at least wanted to hear wether there are some principial contra's against this, because it would be a waste of time if it turned out that one wouldn't ever think of implementing this. And I didn't know wether this has been thought over before. A major point is of course that it would probably break ALL extensions, unless they use Z_LVAL() macro's all the time in stead of zval.value.lval... I'll see wether I can get it more or less running without too much work... My estimate is that the performance inpact will be not more than a few percents, probably lower. But it's an estimate! On the 32bit environments, 64bit integers are implemented as long long, unless you want to implement the 64bit manipulation routines yourself (yikes.) I didn't plan to implement it myself... yikes indeed. The question was wether all compilers on 32bit platforms DO have long long support at all, in other words: is it true that all compilers for which PHP needs to compile have a C-type which is 64bit (native or not)? --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Fw: Bumping PHP to support 8byteintegers
On Mon, 24 Sep 2001, Sascha Schumann wrote: `long long´ support has only become recently adopted by compiler vendors. There are still bugs in common implementations like GCC-2 which is why a program which aims at portability should not depend on it yet. I think that IF it is going to be implemented, it should be a compiler option to choose what the type of integer needs to be: long, long long, or something else... With proper use of macro's that would mean 1 single #define. --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13130 Updated: Safe mode refuses to allow permission
ID: 13130 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Apache related Operating System: RedHat Linux 6.2, kernel 2.4.1 PHP Version: 4.0.6 New Comment: I think it's general permission problem too. But not like you do. Keep in mind that the webserver runs under the user as defined in you httpd.conf. Safe-mode cannot and does not change that. So _first_ safe-mode must allow it, and _second_ apache needs to have write permissions to that file. In you case, safe-mode does allow it (otherwise you'd get a safe-mode error), but your general permissions aren't set correctly. Not a bug. (by the way, you should have asked this on a support forum, www.php.net/support.php ) Previous Comments: [2001-09-23 12:25:32] [EMAIL PROTECTED] Any news yet related to this problem ??? [2001-09-04 08:24:50] [EMAIL PROTECTED] Safe mode appears to be malfunctioning. I've enabled safe mode for the whole server, php scripts appear to work fine, but when a php script attempts to write a file (in a directory owned by the same user as the php script), php complains it can't write. For example, using imagejpeg to export a jpeg file, results in : Warning: imagejpeg: unable to open '/home/photo-user/html/pictures/05090027.JPG' for writing in /home/photo-user/html/functions.inc.php on line 35 Using fopen to write a file gives the same result, so I believe it to be a general permission problem. Also, when I try to use convert (image conversion utility), located in /usr/local/bin (I have added php_admin_value safe_mode_exec_dir /usr/local/bin/ to the Apache config), I get a shell return value of 154 (can't find what it means). PHP should be able to execute that file and have it converting images (writing them back to the directory owned by the user running the php script). The full configure : ./configure --with-apxs=/usr/local/apache/bin/apxs --with-imap --enable-versioning --enable-ftp --with-mysql=/usr/local/mysql --with-snmp=/usr/local/snmp --with-openssl=/usr/local/ssl --enable-dbase --enable-debug --with-pear --with-mcrypt --with-dom --with-pcre --with-zlib-dir=/usr --with-jpeg-dir --with-gd --enable-exif Edit this bug report at http://bugs.php.net/?id=13130edit=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: Undefining user functions/classes at runtime?
Is it currently possible to undefine user functions or classes at runtime? Although not a newbie ;) I'm unsure if its possible right now. No, you can't do that in PHP-userland (in the C code it can be done, see implementation of create_function). And IMHO that should remain so. If not, will this be support (ZE2) ? I hope not. Can you give an example where you think it will be useful? By the way, I think you can achieve something like this if you really want to with Advices, IMHO another needless feature. What I have against those 2 things is that they can have consequences for existing (library) code, since they call, for example, 'rtrim', and with advices c.q. undef'ing functions you can change that behaviour. --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13130 Updated: Safe mode refuses to allow permission
ID: 13130 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache related Operating System: RedHat Linux 6.2, kernel 2.4.1 PHP Version: 4.0.6 New Comment: The answer is no, of course :-) Ask your question via php-general / php-install (more details: http://www.php.net/support.php ) for more info. BTW, safe mode is STRICTER than normal mode, your problems have NOTHING to do with safe-mode. Previous Comments: [2001-09-23 14:04:39] [EMAIL PROTECTED] So, to be able to use safe mode, you should run Apache as root ??? I start Apache as root, but the default user/group is nobody/nobody. [2001-09-23 13:51:35] [EMAIL PROTECTED] I think it's general permission problem too. But not like you do. Keep in mind that the webserver runs under the user as defined in you httpd.conf. Safe-mode cannot and does not change that. So _first_ safe-mode must allow it, and _second_ apache needs to have write permissions to that file. In you case, safe-mode does allow it (otherwise you'd get a safe-mode error), but your general permissions aren't set correctly. Not a bug. (by the way, you should have asked this on a support forum, www.php.net/support.php ) [2001-09-23 12:25:32] [EMAIL PROTECTED] Any news yet related to this problem ??? [2001-09-04 08:24:50] [EMAIL PROTECTED] Safe mode appears to be malfunctioning. I've enabled safe mode for the whole server, php scripts appear to work fine, but when a php script attempts to write a file (in a directory owned by the same user as the php script), php complains it can't write. For example, using imagejpeg to export a jpeg file, results in : Warning: imagejpeg: unable to open '/home/photo-user/html/pictures/05090027.JPG' for writing in /home/photo-user/html/functions.inc.php on line 35 Using fopen to write a file gives the same result, so I believe it to be a general permission problem. Also, when I try to use convert (image conversion utility), located in /usr/local/bin (I have added php_admin_value safe_mode_exec_dir /usr/local/bin/ to the Apache config), I get a shell return value of 154 (can't find what it means). PHP should be able to execute that file and have it converting images (writing them back to the directory owned by the user running the php script). The full configure : ./configure --with-apxs=/usr/local/apache/bin/apxs --with-imap --enable-versioning --enable-ftp --with-mysql=/usr/local/mysql --with-snmp=/usr/local/snmp --with-openssl=/usr/local/ssl --enable-dbase --enable-debug --with-pear --with-mcrypt --with-dom --with-pcre --with-zlib-dir=/usr --with-jpeg-dir --with-gd --enable-exif Edit this bug report at http://bugs.php.net/?id=13130edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13406 Updated: PHP exploit
ID: 13406 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: *General Issues Operating System: Linux PHP Version: 4.0.4pl1 New Comment: Ask support questions on http://www.php.net/support.php Hint: safe-mode, safemode.disable-function (or something like that) Previous Comments: [2001-09-23 14:27:10] [EMAIL PROTECTED] I'm running Redhat 7.1 Linux 2.4.3-12 #1 Fri Jun 8 15:05:56 EDT 2001 i686 unknown with apache apache-1.3.19-5 funcion system() gives apache rights to every user even in /~username requests... it is easy to exploit the whole site with simple script http://www.gimpster.com/php/phpshell/index.php what should I do againt.?? Edit this bug report at http://bugs.php.net/?id=13406edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13407 Updated: array index 2147483647 not equivalent to 2147483647
ID: 13407 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Unknown/Other Function Operating System: PHP Version: 4.0.4pl1 New Comment: Integers are limited in capacity, you're too near the bounds of integer. If you need such high numbers, see GMP. Not a bug. (though technically it could be possible to let this single number work, the next one will fail.) Do a var_dump($ar) to see what happens. Previous Comments: [2001-09-23 14:44:33] [EMAIL PROTECTED] $ar[2147483646]=apples; $ar[2147483647]=oranges; echo $ar[2147483646]; echo $ar[2147483647]; produces: apples Edit this bug report at http://bugs.php.net/?id=13407edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13407 Updated: array index 2147483647 not equivalent to 2147483647
ID: 13407 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Unknown/Other Function Operating System: PHP Version: 4.0.4pl1 New Comment: I assume there somewhere needs to be one more than the index, for some reason... people should, IMHO, realize that computers have limited capacity for integer numbers, well, at least most languages do. And wether it goes wrong at max-1 or exactly at max, isn't really an issue IMO. You should not rely on the outer regions of the capacity of integer numbers. But there is one other reason why this isn't bogus after all, because $ar[ digits ] and $ar[ digits ] (digits := [0-9]+ ) should be equivalent. This is true inside the bounds (because both come down to an integer), and outside the bounds (because both come down to the same string). But for this case it is NOT true... Previous Comments: [2001-09-23 14:59:10] [EMAIL PROTECTED] Hrm.. Sure, that is the kneejerk response, but too near? 2147483647 is 2^31 - 1. I could understand if this happened at 2^31+1 and up, but not at 2^31 - 1. I'd like to see a better explanation of why this happens at instead of at 21474836478 [2001-09-23 14:52:16] [EMAIL PROTECTED] Integers are limited in capacity, you're too near the bounds of integer. If you need such high numbers, see GMP. Not a bug. (though technically it could be possible to let this single number work, the next one will fail.) Do a var_dump($ar) to see what happens. [2001-09-23 14:44:33] [EMAIL PROTECTED] $ar[2147483646]=apples; $ar[2147483647]=oranges; echo $ar[2147483646]; echo $ar[2147483647]; produces: apples Edit this bug report at http://bugs.php.net/?id=13407edit=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] Fw: Bumping PHP to support 8byte integers
Hi, For a scripting language, integers should IMHO be bounded by a number that will reasonally not be bound by numbers that will be used in normal scripts. That is currently not the case, 4 bytes are insufficient IMHO. Why not make sure PHP uses 8 bytes at least? Or are there platforms not supporting 8byte integers? I believe most popular do... (at least linux on i586 and i686, windows and Solaris (I tested SunOS 5.6)) For implementation, I think that we should introduce p_int and p_float typedefs for php-integer and php-float anyway, and changing THAT isn't a problem. About preformance/memory, I think that's not an issue. Making strings unicode will be much more heavy for PHP... --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13407 Updated: array index 2147483647 not equivalent to 2147483647
ID: 13407 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Unknown/Other Function Operating System: PHP Version: 4.0.4pl1 New Comment: I assume there somewhere needs to be one more than the index, for some reason... people should, IMHO, realize that computers have limited capacity for integer numbers, well, at least most languages do. And wether it goes wrong at max-1 or exactly at max, isn't really an issue IMO. You should not rely on the outer regions of the capacity of integer numbers. But there is one other reason why this isn't bogus after all, because $ar[ digits ] and $ar[ digits ] (digits := [0-9]+ ) should be equivalent. This is true inside the bounds (because both come down to an integer), and outside the bounds (because both come down to the same string). But for this case it is NOT true... Previous Comments: [2001-09-23 15:06:43] [EMAIL PROTECTED] I assume there somewhere needs to be one more than the index, for some reason... people should, IMHO, realize that computers have limited capacity for integer numbers, well, at least most languages do. And wether it goes wrong at max-1 or exactly at max, isn't really an issue IMO. You should not rely on the outer regions of the capacity of integer numbers. But there is one other reason why this isn't bogus after all, because $ar[ digits ] and $ar[ digits ] (digits := [0-9]+ ) should be equivalent. This is true inside the bounds (because both come down to an integer), and outside the bounds (because both come down to the same string). But for this case it is NOT true... [2001-09-23 14:59:10] [EMAIL PROTECTED] Hrm.. Sure, that is the kneejerk response, but too near? 2147483647 is 2^31 - 1. I could understand if this happened at 2^31+1 and up, but not at 2^31 - 1. I'd like to see a better explanation of why this happens at instead of at 21474836478 [2001-09-23 14:52:16] [EMAIL PROTECTED] Integers are limited in capacity, you're too near the bounds of integer. If you need such high numbers, see GMP. Not a bug. (though technically it could be possible to let this single number work, the next one will fail.) Do a var_dump($ar) to see what happens. [2001-09-23 14:44:33] [EMAIL PROTECTED] $ar[2147483646]=apples; $ar[2147483647]=oranges; echo $ar[2147483646]; echo $ar[2147483647]; produces: apples Edit this bug report at http://bugs.php.net/?id=13407edit=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: [Zend Engine 2] Bumping PHP to support 8byte integers
Hi, For a scripting language, integers should IMHO be bounded by a number that will reasonally not be bound by numbers that will be used in normal scripts. That is currently not the case, 4 bytes are insufficient IMHO. Why not make sure PHP uses 8 bytes at least? Or are there platforms not supporting 8byte integers? I believe most popular do... (at least linux on i586 and i686, windows and Solaris (I tested SunOS 5.6)) An other advantage IMHO is that 64-bit integers can represent any integer that can - in float format - be distinguished from it's neighbour. Recall that C-double == PHP-float have at least 64-bits, so a mantissa of 64bits. So any number n for which n and n+1 are distingwishable in 64-bit floating point numbers, must fall in the range of 64-bit integers. For implementation, I think that we should introduce p_int and p_float typedefs for php-integer and php-float anyway, and changing THAT isn't a problem. About preformance/memory, I think that's not an issue. Making strings unicode will be much more heavy for PHP... --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Bumping PHP to support 8byte integers
On Sun, 23 Sep 2001, Andi Gutmans wrote: We should check with the MySQL guys what the performance implications are. I remember they had a contest for the fastest longlong2str() function. I guess this was due to performance problems. We should also at least see if this would cause problems with all sorts of standard functions missing for long long such as strtol(). I guess stroll? It works with me. supporting long long's is more than just changing the type in the zval. I do realize that... Most extensions assume the type is 'long', so that needs to be fixed first. No matter how you look at it, it will be big job to do. In PHP performance is IMHO a bit less important than in DBMS's. If you're after performance you shouldn't use a scripting language anyway :). But if this would have a major performance penalty, it's something different... I'll time stroll and strtol to see how much slower it is. Anyway, it would be nice if someone with expericence with changing to 8 byte integers could share his experiences... --Jeroen Andi At 09:13 PM 9/23/2001 +0200, Jeroen van Wolffelaar wrote: Hi, For a scripting language, integers should IMHO be bounded by a number that will reasonally not be bound by numbers that will be used in normal scripts. That is currently not the case, 4 bytes are insufficient IMHO. Why not make sure PHP uses 8 bytes at least? Or are there platforms not supporting 8byte integers? I believe most popular do... (at least linux on i586 and i686, windows and Solaris (I tested SunOS 5.6)) For implementation, I think that we should introduce p_int and p_float typedefs for php-integer and php-float anyway, and changing THAT isn't a problem. About preformance/memory, I think that's not an issue. Making strings unicode will be much more heavy for PHP... --Jeroen Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Fw: Bumping PHP to support 8byte integers
I would be very worried about making numbers 8 bytes by default, unless the CPU supports them natively. There are a lot of consequenses involved with something like that. Assuming a 32 bit register system (x86) integers will no longer fit in registers. This changes EVERYTHING, from passing them to functions, to how arithatic is performed. Nor am I sure what the state of compilers are in all PHP's supported environments, do the compilers handle long long? These are problems indeed, it is just an idea, I don't know what the performance impacts are. Unfortunately it's quite a work to change it, otherwise it's a question of trying it and see what the impact is on typical scripts. For compilers possibly not supporting long long, it's about wether they support 64bit integers. Does someone know how the support of 64bit integers is in compiler-land? --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Bumping PHP to support 8byte integers (fwd)
This subject is being crossposted to [EMAIL PROTECTED] and [EMAIL PROTECTED] This mail was only on engine2 (let's keep everyting at least on phpdev): -- Forwarded message -- Date: Sun, 23 Sep 2001 22:41:45 +0200 (CEST) From: Jeroen van Wolffelaar [EMAIL PROTECTED] To: Stig Sæther Bakken [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Zend Engine 2] Bumping PHP to support 8byte integers On 23 Sep 2001, Stig Sæther Bakken wrote: [Jeroen van Wolffelaar [EMAIL PROTECTED]] Hi, For a scripting language, integers should IMHO be bounded by a number that will reasonally not be bound by numbers that will be used in normal scripts. That is currently not the case, 4 bytes are insufficient IMHO. Why not make sure PHP uses 8 bytes at least? Or are there platforms not supporting 8byte integers? I believe most popular do... (at least linux on i586 and i686, windows and Solaris (I tested SunOS 5.6)) For implementation, I think that we should introduce p_int and p_float typedefs for php-integer and php-float anyway, and changing THAT isn't a problem. About preformance/memory, I think that's not an issue. Making strings unicode will be much more heavy for PHP... I don't know what you had in mind, but replacing long lval with long long lval will increase the size of _every_ zval from 8 to 12 bytes. That's indeed a big issue, since it requires more memory _and_ cpu (more data to move around). zval.value is an union with: (4byte)long lval (8byte)double dval (8byte)struct str (4byte)*ht (8byte)stuct obj So not more cpu time in moving around, since C does not know it doesn't need to copy the last 4 bytes in the union. The size of zval will remain value+type+is_ref+refcount = 8+1+1+2 = 12. - Stig Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Confirmed: False positive in php_ mhash.dll with AntiVir software
FYI, I mailed the authors of that virus program, and they replied the following: - Original Message - From: H+BEDV Datentechnik GmbH [EMAIL PROTECTED] To: Jeroen van Wolffelaar [EMAIL PROTECTED] Sent: Friday, September 21, 2001 11:42 AM Subject: Re: False positive in PHP-distribution Dear Mr. Wolffelaar, thanks for your email. We have a false positiv with this file. With the new update from AntiVir cam not a false positiv. Sorry for the trouble. With kind regards AntiVir Support Team H+BEDV Datentechnik GmbH -- 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 #13384 Updated: Enctype multipart/form-date
ID: 13384 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Unknown/Other Function Operating System: Linux hurricane 2.2.19-5tr PHP Version: 4.0.6 New Comment: Can you provide a short script which is showing this problem? And you should use enctype=multipart/form-data (with the quotes), because without it's invalid HTML (only [a-zA-Z0-9.-]+ is allowed in HTML-attribute values without quotes, see http://www.htmlhelp.com/reference/html40/structure.html#attributes) Previous Comments: [2001-09-21 21:10:03] [EMAIL PROTECTED] Is Linux hurricane a RedHat based distribution and you are using the distributions PHP RPMs? [2001-09-21 20:40:14] [EMAIL PROTECTED] I'm not sure it's a bug. But I have checked all of my configuration system and I think the problem is not in my system. The problem is : When i used tag form and enctype=multipart/form-data (we must use this for input type=file or for upload file), There's no variables delivered to 'action' file. The problem disappeared if I use PHP 4.0.5 with the exactly same script and everthing is ok for the form. That's all, pls reply if you're have found the solution for me. Thanks a lot Edit this bug report at http://bugs.php.net/?id=13384edit=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: Bug #13388 Updated: Could not connect to server
How can you determine it is bogus within 2 minutes, please provide your rational. (...) This is probably not a bug ? Are you kidding me ? I hope you are not closing any real nasty bugs because of this reasoning :) From http://www.chiark.greenend.org.uk/~sgtatham/bugs.html Give the programmer some credit for basic intelligence: if the program really didn't work at all, they would probably have noticed. Since they haven't noticed, it must be working for them. Therefore, either you are doing something differently from them, or your environment is different from theirs. They need information; providing this information is the purpose of a bug report. More information is almost always better than less. This isn't really a case of a program not working at all, but somebody coded this feature, and it does work. So you're either doing something wrong, or the cause is in your specific enviroment. Since you're using windows (a popular and widely-used platform, and therefore much tested), Derick guessed - and I think he's right - that you were doing something wrong. To find it out, see the support forums, (http://www.php.net/support.php), because they are there for things like this. If they come to the conclusing this is a bug, you can report it again. --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11945 Updated: ignore
ID: 11945 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: ugly bug PHP Version: 4.0.6 New Comment: Test timing settings of www.php.net (off by approx. 9 or 10 hours) Previous Comments: [2001-07-10 17:01:17] just testing [2001-07-07 12:33:09] [EMAIL PROTECTED] please ignore Edit this bug report at http://bugs.php.net/?id=11945edit=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] Time of www.php.net incorrect
I posted a bug-update 5 minutes ago, and from the mail headers: Date: 22 Sep 2001 10:34:57 - It is now GMT/UTC 21 sep 2001 22:30 or something. That means that bugs.php.net is off-time by 12 hours, which is very annoying. (chronology of posts is completely wrong). Can someone please fix this? --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: TSRM again
Jeroen, then i have one more question. The real problem im trying to solve is Would some one please answer this question, because this is getting somewhere (mutexs) I don't know much of. And not much is nearly nothing in this case ;-) --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Rand - continue or not?
By special request: These are the pro's and contra's to the current proposal currently known with me. (see: http://www.A-Eskwadraat.nl/~jeroen/rand/ ) ###Pro's: * Hide seeding and such from the php-programmer * All randomness controllable, with clear syntax. * The choice-for-algorithm should NOT be to the php-programmer if you're after random numbers. * Make it _possible_ to add a real-random-number generator which will be used by PHP * Namespace-cleaning: rand, srand, getrandmax, mt_rand, mt_srand, mt_getrandmax and lcg_value not needed anymore, simply 'random', 'random_set', and possibly 'random_value' for getting a [0,1) float. ###Contra's: * Slower: [My code was less than 1% slower, so it's neglectable] * More complicated C-code [True] * Leaks, bad coding style, etc: [Implementation isn't discussed here] * Don't fix if it isn't broken [This is no fix, it's better syntax] Based on these arguments, I don't see any reason why not to go on. If anyone does see a reason, and/or I missed an argument, please mail it to php-dev and/or myself. TIA, Jeroen PS: The proposal is slightly updated because of a suggestion by someone (Joey IIRC) -- 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] TSRM coverage question
On Tue, 18 Sep 2001, lo-tek @pb1.pair.com cshmoove wrote:
suppose i have a function which returns a pointer to a variable in
thread
local storage
foo_t *get_global_foo()
{
TSRMLS_FETCH();
return (foo_t *)BAR_G(foo);
}
void fubar()
{
foo_t *foo = get_global_foo();
bar( foo );/* possible multi-thread access */
}
is fubar then thread safe, or is TSRMLS_FETCH() (or TSRMLS_C etc) needed
in
each function needing serialized access to TLS data ?
Well, your just tossing around pointers (your returning a pointer to
an address in the global structure which is assigned to foo, which
you then pass to bar). So thread safety should *not* be affected.
But AFAIK TSRM* do NOT force serialized execution of functions, they just
make sure that each uses a different set of php-globals. So if bar( ) is not
thread-safe, the whole function still won't be thread safe, no matter
whether you use TSRM. It simply depends on the bar( ) function.
I don't know what the solution should be, of course it will be some kind of
locking, but I don't know what would be the best solution.
--Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13353 Updated: function calling causes error with varable
ID: 13353
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Closed
Status: Bogus
Bug Type: Variables related
Operating System: win 98 box
PHP Version: 4.0.4pl1
Previous Comments:
[2001-09-17 16:26:15] [EMAIL PROTECTED]
I am not sure if this is a bug or php is just not built to handle something like this,
but when i call a function like this:
function
EchoContent($BarName=Error,$body=error.inc,$topheight=100,$width=$menuwidth){
it causes an error! you cant assign a variable within the function call.
i would have to re-do it like this for it not to cause an error.
function
EchoContent($BarName=Error,$body=error.inc,$topheight=100,$width=100){
I am sure you can see the benefits of using the top version.
Knight
Edit this bug report at http://bugs.php.net/?id=13353edit=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: array_sum() needed but not available in 4.0.4 versions..
How can I add the function array_sum() to older php core installations? Grep though the current source with 'array_sum', and add the three things that come up to your 4.0.3-source: a proto in a .h-file, a PHP_FE entry, and the PHP_FUNCTION itself. It should work... but why not simply upgrade? By the way, it is very easy to implement the function in php itself, it's just a bit less efficient than the core-version. --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Rand...
Hi all,
There has been a bit of discussion about rand(). I really appreciate that,
though I would have preferred if it was held BEFORE the changes I (tried to)
make.
Okay, back to business.
By special request, as short as possible:
(I assume you've read the latest proposal, if not, go to
http://www.a-es2.uu.nl/~jeroen/rand/ )
[This part only applies to the controversary part of the proposal, AKA the
'redesign' (which it isn't anymore)]
###Pro's:
* Easier for the user
* All randomness controllable (wasn't the case before).
* The choice-for-algorithm should NOT be to the php-programmer if you're
after random numbers. (this is very important)
* Make it _possible_ to add a real-random-number generator which will be
used by PHP
* Namespace-cleaning: rand, srand, getrandmax, mt_rand, mt_srand,
mt_getrandmax and lcg_value not needed anymore, simply 'random',
'random_set', and possibly 'random_value' for getting a [0,1) float.
###Contra's:
* Slower: not significantly, comparing just-before-jani's-revert and
just-after-jani's-revert, it turns out that the new way is 14 ns slower
(1387ns vs 1373ns). To compare: 1 + 1 takes 712 ns. All this on a quite old
300MHz machine. And the code wasn't optimized at all.
(recall that there go 10 (10^9) nanoseconds in a second)
[I did 10x 1000 (10 x 10^7) experiments, and applied some statistics,
and concluded that the measurement results are accurate to a few
nanoseconds]
* More complicated C-code: True of course, but is that really a reason?
* Leaks, bad coding style, etc: Code wasn't finished yet, of course, that
needs (and will be) fixed, but that's not the issue in this stage
* Don't fix if it isn't broken: This is not a fix. And it 'fixes' the
disadvantages of the current system mentioned in pro's.
### Stop reading here, and comment on these pro's and contra's (especially
if I forgot one). Unless you're really interested, you could read further. A
bit more below, there are some sample scripts.
Other proposed changes are without any objections, and can also be
implemented quite straight-forwardly:
* Easy seeding by user
Sterling recently enhanced srand() to invent a seed by itself. There was
also no discussion about this point.
* Seeding on script startup
There are no objections, so that should be added soon. It is already done
iff you have crypt()
* Thread safe rand()
Can be done, and should be done IMHO. This is no big deal either. 3.3073802
==
Okay, now some examples from practice, why the one way is easier:
php.ini: random_generator = mt
?php // this script uses MT all over:
echo random();
$a = array('a','b','c');
var_dump(shuffle($a)); // uses mt
?
?php // this script uses lcg all over, and will produce same output each
time
// differs from previes script only by first line.
random_set(RAND_LCG, 123);
echo random();
$a = array('a','b','c');
var_dump(shuffle($a));
?
# how to extend:
php.ini:
random_generator = random.org
?php // uses true random numbers
echo random();
$a = array('a','b','c');
var_dump(shuffle($a)); // uses mt
?
php.ini: irrelevant
?php // this script uses MT all over:
// force mt-generation. This is something that shouldn't happen in good
scripts. Which one is the best random-number-generator can only be decided
by system-admin (because could be system-dependent)
ini_set(random_number_generator, mt);
echo random();
$a = array('a','b','c');
var_dump(shuffle($a)); // uses mt
?
===
Currently, you cannot control all randomness, you cannot decide what
algorithm shuffle co should use, you need to change all calls to rand() if
you decide to switch to other algorithm.
Currently there are 3 random number generators in the core of PHP, all are
different and have there specific properties. They should be easily easy to
use, which isn't the case now. lcg for example can't
currently be used well as integer-yielding function.
--Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #12690 Updated: array_unique under windows does not work as it does under linux
then why does this work in version 4.0.4 ? It was an implementation side-effect. It was not intentionally. The same issue as that, for example, you can specify a variable violating the naming rules by using: $GLOBALS[0a\n] = Some value; because it would be bad for performance to check for validness of the variable-name, and it isn't easy to do either. Nevertheless you should not trust on this capability: It could change in the future. See also bug 12367, the comments by [EMAIL PROTECTED] --Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13277 Updated: amp; in query_string are not handled
ID: 13277 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Variables related Operating System: Debian GNU/Linux PHP Version: 4.0.6 New Comment: This is wrong. amp; is the way to specify in HTML. For example: a href=script.php?var1=valueamp;var2=othervalueClick here to continue/a But the browser should (according to HTML-specs) request this uri: script.php?var1=valuevar2=othervalue from internet (i.e., your script) If the browser doesn't do that, it's a browser bug. Previous Comments: [2001-09-12 20:00:05] [EMAIL PROTECTED] The query_string a=1b=2 and a=1amp;b=2 should be equivalent, but they are not with php. A workaround is to use arg_separator.input = ;. Edit this bug report at http://bugs.php.net/?id=13277edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11338 Updated: arraydiff returns a vector with empty values for found values
ID: 11338
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Arrays related
Operating System: True64Unix 5.1
PHP Version: 4.0.5
New Comment:
Both array_diff and array_intersect preserve keys.
I don't see the problem here? array_diff and array_intersect are completely symmetric.
var_dump(array_intersect(array('a','b'), array('b')));
var_dump(array_diff (array('a','b'), array('a')));
array(1) {
[1]=
string(1) b
}
array(1) {
[1]=
string(1) b
}
Previous Comments:
[2001-06-07 16:07:50] [EMAIL PROTECTED]
Hi,
I found the following behaviour not normaland at least not reflecting what
is said in the documentation
using arraydiff alone returns *en#nl
there is an empty value field at the place of the removed
component of the array
There is an empty field between and * !!
$lang=array(fr,en,nl);
$lg1=array(fr);
$olang=(array_diff($lang,$lg1);
echo ,$olang[0],*,$olang[1],#,$olang[2],\n;
The resulting vector is not shorter !!
1) This is not matching what is said in the documentation and can makes a
programmer loose time trying to find why it is not working as he expected,
We would have expected a behaviour closer to array_intersect which is
returning an array with only the significant values...!
2) this is removing symetry of behaviour of array_diff compared to
array_intersect
The following workaround solves the problem, but needs at least to CLEARLY
be mentioned in the documentation of the usage of the array_diff function,
if it would not be planned to improve the behaviour of the function in the expected
way
$olang=array_values(array_diff($lang,$lg1));
echo 2,$olang[0],*,$olang[1],#,$olang[2],\n;
regards,
[EMAIL PROTECTED]
Edit this bug report at http://bugs.php.net/?id=11338edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10658 Updated: array_diff does not work with classes
ID: 10658
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Suspended
Bug Type: Arrays related
Operating System: Linux
PHP Version: 4.0.5
New Comment:
The problem is that array_diff compares the string-represantation of the arguments.
And in the case of objects, it is always Object, and thus considered equal.
This is currently expected behaviour, though it'd be be better if it weren't...
string-comparasation by array_diff co is not satisfactionary in case of objects.
(nor arrays)
Suspended.
Previous Comments:
[2001-05-04 03:36:46] [EMAIL PROTECTED]
Consider the following script:
?
class test
{
var $x;
var $y;
function test ()
{
$this-x = 0;
$this-y = 0;
}
function set ($x, $y)
{
$this-x = $x;
$this-y = $y;
}
}
$mumu = array();
$gaga = array();
for($i=0;$i3;$i++)
{
$test = new test ();
$test-set($i, $i);
$mumu[xx.$i] = $test;
}
for($i=0;$i5;$i++)
{
$test = new test ();
$test-set($i, $i);
$gaga[xx.$i] = $test;
}
$fff = array_diff($mumu, $gaga);
$ggg = array_diff($gaga, $mumu);
echo pre;
print_r($fff);
echo /pre;
echo pre;
print_r($ggg);
echo /pre;
?
the following is the output from a server with php
4.0.4pl1:
Array
(
)
Array
(
[xx3] = test Object
(
[x] = 3
[y] = 3
)
[xx4] = test Object
(
[x] = 4
[y] = 4
)
)
and the following is the ouput with php 4.0.5:
Array
(
)
Array
(
)
the php.ini is the same on both servers.
Edit this bug report at http://bugs.php.net/?id=10658edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12201 Updated: Order in array function
ID: 12201 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Arrays related Operating System: UNIX PHP Version: 4.0.6 New Comment: Sample script? Previous Comments: [2001-07-17 07:01:39] [EMAIL PROTECTED] array_diff and array_intersect (maybe also other array functions) change the original order from compared arrays, could you keep the initial order? Thanks Edit this bug report at http://bugs.php.net/?id=12201edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11893 Updated: array_intersect doesn't handle multidimensional arrays correctly
ID: 11893
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Arrays related
Operating System: Linux, FreeBSD, OpenBSD (Any?)
PHP Version: 4.0.6
New Comment:
array_intersect isn't supposed to handle multi-dimmed arrays.
Where have you read that? Not in the manual in any case.
Previous Comments:
[2001-07-04 19:49:53] [EMAIL PROTECTED]
michael@zaphod:~php
?
$a = array(array(1, a), array(2, b), array(3, c));
$b = array(array(1, a), array(2, b), array(4, d));
$c = array_intersect($a, $b);
var_dump($c);
?
X-Powered-By: PHP/4.0.6
Content-type: text/html
array(3) {
[0]=
array(2) {
[0]=
int(1)
[1]=
string(1) a
}
[1]=
array(2) {
[0]=
int(2)
[1]=
string(1) b
}
[2]=
array(2) {
[0]=
int(3)
[1]=
string(1) c
}
}
The same thing happens in 4.0.5.
For comparison 4.0.4pl1-Output (and as I expect it to be):
X-Powered-By: PHP/4.0.4pl1
Content-type: text/html
array(2) {
[0]=
array(2) {
[0]=
int(1)
[1]=
string(1) a
}
[1]=
array(2) {
[0]=
int(2)
[1]=
string(1) b
}
}
Edit this bug report at http://bugs.php.net/?id=11893edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10891 Updated: array_unique does not work properly anymore
ID: 10891
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Arrays related
Operating System: UNIX FreeBSD 4.1.1
PHP Version: 4.0.5
New Comment:
Array_unique isn't supposed to handle multi-dimension strings, nor objects.
See also 10658
Previous Comments:
[2001-05-16 03:28:28] [EMAIL PROTECTED]
I've installed php 4.0.5 and function array_unique does not work correctly anymore.
The following code works with 4.0.3pl1 as it's supposed to do:
?
$arr[0][] = 1;
$arr[0][] = 2;
$arr[0][] = 3;
$arr[1][] = 1;
$arr[1][] = 2;
$arr[1][] = 3;
$arr[2][] = 1;
$arr[2][] = 2;
$arr[2][] = 5;
$arr = array_unique($arr);
while(list(,$n) = each($arr)) echo implode(',',$n).br;
?
Output is :
1,2,3
1,2,5
But with php 4.0.5 it refuses to work and returns : 1,2,3
I've looked through source code ext/standard/array.c and revealed some differences
between 4.0.3 - 4.0.5:
set_compare_func(SORT_STRING); - 4.0.5
set_compare_func(SORT_REGULAR); - 4.0.3
Some others functions array_* also use SORT_STRING comparing instead of SORT_REGULAR
Best regards,
Konstantin,
http://itc-ua.com
Edit this bug report at http://bugs.php.net/?id=10891edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12528 Updated: array_unique function changed
ID: 12528
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Arrays related
Operating System: linux
PHP Version: 4.0.6
New Comment:
Array_unique isn't supposed to handle multi-dimension strings, nor objects.
See also 10658
Previous Comments:
[2001-08-02 05:39:03] [EMAIL PROTECTED]
My ISP recently upgraded from 4.0.3pl1 to 4.0.6 - i have a script that runs an
'array_unique' on a 2d array. This used to work previously, but now it reduces the
array down to a single item.
Here is the section of script:
// CLEAN UP DUPLICATES THAT DON'T HAVE THE DESCRIPTION, BUT ARE THE SAME SECTION
if ( $debug ) echo P
style='text-align:left'BCLEAN UP DUPLICATE SECTIONS/BBR
I[\$idx,\$count].../IBR;
$count = 0;
for ( $idx = 0; $idx count($section_result); ++$idx
) {
$comp1 = strtolower($section_result[$idx][0]);
$comp2 =
strtolower($section_result[$idx+1][0]);
$comp3 =
strtolower($section_result[$idx-1][0]);
if ( $comp1 == $comp2 ) {
// IF THIS ENTRY IS THE SAME SECTION AS THE
NEXT ONE
if ( $section_result[$idx+1][1] != ''
) {
$section[$count][0] =
$section_result[$idx+1][0];
$section[$count][1] =
$section_result[$idx+1][1];
++$count;
} elseif ( $section_result[$idx][1] !=
'' ) {
$section[$count][0] =
$section_result[$idx][0];
$section[$count][1] =
$section_result[$idx][1];
++$count;
}
} elseif ( $comp1 != $comp3 ) {
$section[$count][0] =
$section_result[$idx][0];
$section[$count][1] =
$section_result[$idx][1];
++$count;
}
if ( $debug ) echo [$idx,$count] .
$section[$count-1][0] . -- . $section[$count-1][1] . BR;
} // close for
if ( $debug ) echo /P;
$section = array_unique($section);
if ( $debug ) {
echo P style='text-align:left'BUNIQUE
SECTIONS AFTER CLEAN-UP/BBR;
echo section count: . count($section) . |
$countBR;
echo IWork it thru a 'for' loop:/IBR;
for ( $idx = 0; $idx $count; ++$idx ) {
echo $section[$idx][0] . -- .
$section[$idx][1] . BR;
}
echo IWork it thru a 'foreach'
loop:/IBR;
foreach ( $section as $message ) {
echo $message[0] . -- .
$message[1] . BR;
}
echo /P;
echo P style='text-align:left'BUNIQUE
SECTION_RESULT AFTER CLEAN-UP/BBR;
foreach ( $section_result as $message ) {
echo $message[0] . -- .
$message[1] . BR;
}
echo /P;
}
Edit this bug report at http://bugs.php.net/?id=12528edit=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]
