[PHP-DEV] Bug #14271: Failure to compile using GD 2.0.1 because of conflicting types for gdIOCtx
From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.1.0 PHP Bug Type: Compile Failure Bug description: Failure to compile using GD 2.0.1 because of conflicting types for gdIOCtx When compiling w/ GD 2.0.1, I found a warning and a fatal error: In file included from gd.c:36: php_gd.h:69: warning: static declaration for `gdImageColorResolve' follows non-static gd.c:92: conflicting types for `gdIOCtx' /asd/metallo1/server/libs/gd2/include/gd_io.h:19: previous declaration of `gdIOCtx' make[3]: *** [gd.lo] Error 1 make[3]: Leaving directory `/asd/metallo1/sources/src_compile/php-4.1.0/ext/gd' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/asd/metallo1/sources/src_compile/php-4.1.0/ext/gd' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/asd/metallo1/sources/src_compile/php-4.1.0/ext' make: *** [all-recursive] Error 1 Using gcc 3.0.2, gd 2.0.1, and the following configuration line: ./configure --prefix=/export/dredox1/devel_server/php \ --with-config-file-path=/export/dredox1/devel_server/php \ --enable-track-vars --enable-magic-quotes \ --enable-inline-optimization --enable-xml --enable-wddx \ --enable-ftp --enable-calendar --enable-bcmath --enable-trans-id\ --with-zlib \ --with-gd=/asd/metallo1/server/libs/gd2 \ --enable-gd-native-ttf \ --with-xmlrpc \ --with-mysql=/export/dredox1/devel_server/mysql \ --with-apxs=/export/dredox1/devel_server/apache/bin/apxs A quick and dirty kludge is to comment out line 92 in ext/gd/gd.c, which might break something else. Had not tested the compiled libphp4.so thoroughly. -- Edit bug report at: http://bugs.php.net/?id=14271edit=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 #14138 Updated: date arithmetic scrambled
ID: 14138
Updated by: jmcastagnetto
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Date/time related
Operating System: Debian GNU/Linux stable
PHP Version: 4.0.6
New Comment:
Perhaps a problem with the Debian libraries, cannot confirm problem on PHP 4.0.6 under
Solaris 2.8. Output of the code is correct in that machine and PHP version.
Code also tested by _RainMkr_ (from #php) using PHP 4.0.6 under Linux 2.4.5
Need feedback on whether other numeric programs have similar problems under that
version of Debian.
Previous Comments:
[2001-11-20 04:47:13] [EMAIL PROTECTED]
Works fine for me, can you try the RC from www.php.net/~zeev/php-4.1.0RC3.tar.gz ?
Derick
[2001-11-20 04:43:47] [EMAIL PROTECTED]
There seems to be some voodoo in this script ...
for ( $i = -7 ; $i 28 ; $i ++ ) {
$day = date('d');
print \ndate is $day ;
$day = $day + $i;
print after adding $i is $day ;
}
And output ends up looking like so:
date is 20 after adding -7 is 135122101
Edit this bug report at http://bugs.php.net/?id=14138edit=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 #14138 Updated: date arithmetic scrambled
ID: 14138
Updated by: jmcastagnetto
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Date/time related
Operating System: Debian GNU/Linux stable
PHP Version: 4.0.6
New Comment:
More info from _RainMkr_: Running on woody, Linux 2.4.5, PHP 4.0.6
What version is the Debian showing this problem?
Previous Comments:
[2001-11-20 22:35:38] [EMAIL PROTECTED]
Perhaps a problem with the Debian libraries, cannot confirm problem on PHP 4.0.6 under
Solaris 2.8. Output of the code is correct in that machine and PHP version.
Code also tested by _RainMkr_ (from #php) using PHP 4.0.6 under Linux 2.4.5
Need feedback on whether other numeric programs have similar problems under that
version of Debian.
[2001-11-20 04:47:13] [EMAIL PROTECTED]
Works fine for me, can you try the RC from www.php.net/~zeev/php-4.1.0RC3.tar.gz ?
Derick
[2001-11-20 04:43:47] [EMAIL PROTECTED]
There seems to be some voodoo in this script ...
for ( $i = -7 ; $i 28 ; $i ++ ) {
$day = date('d');
print \ndate is $day ;
$day = $day + $i;
print after adding $i is $day ;
}
And output ends up looking like so:
date is 20 after adding -7 is 135122101
Edit this bug report at http://bugs.php.net/?id=14138edit=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 #12658 Updated: set_error_handler() not working properly (with 'Call to undefined function')
ID: 12658
Updated by: jmcastagnetto
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Red Hat Linux, Win2000 sp2
PHP Version: 4.0.6
Old Assigned To:
Assigned To: jmcastagnetto
New Comment:
The assertion ... Seems that PHP cannot redirect 'Call to undefined function' errors
to a custom error
handler... is incorrect.
This seems to be a problem w/ the person reporting the bug *not* using the
error_reporting() function, as it is clearly noted in the manual example, changing the
code to read:
?php
define (ERROR,E_USER_WARNING);
define (WARNING,E_USER_NOTICE);
// set the error reporting level for this script
error_reporting (FATAL | ERROR | WARNING);
// Define a simple error handler
function error_handler ($level, $message, $file, $line, $context) {
echo An error of level $level was generated in file $file on line $line.
\nThe error message was: $message \nThe following variables were set in the
scope that the error occurred in: blockquote ;
print_r ($context);
print \n/blockquote;
}
// Set the error handler to the error_handler() function
set_error_handler ('error_handler');
trigger_error (Some other error);
whatever();
?
The output is:
An error of level 1024 was generated in file bugtest.php on line 20.
The error message was: Some other error
The following variables were set in the
scope that the error occurred in: blockquote
Array (
[PWD] = /tmp
[... snip ...]
[_] = /usr/local/bin/php
[PHP_SELF] =
[argv] = Array
(
[0] = bugtest.php
)
[argc] = 1
[HTTP_POST_VARS] = Array
(
)
[HTTP_GET_VARS] = Array
[...snip...]
/blockquote
This was tested with 4.0.6 on RH 7.1, more information is requested from the person
reporting the bug, before it is reclassified as bogus.
Previous Comments:
[2001-08-08 13:23:32] [EMAIL PROTECTED]
Seems that PHP cannot redirect 'Call to undefined function' errors to a custom error
handler...
A sample (taken partly from the manual):
pre
?php
// Define a simple error handler
function error_handler ($level, $message, $file, $line, $context) {
echo An error of level $level was generated in file $file on line $line. \nThe error
message was: $message \nThe following variables were set in the scope that the error
occurred in: blockquote ;
print_r ($context);
print \n/blockquote;
}
// Set the error handler to the error_handler() function
set_error_handler ('error_handler');
trigger_error (Some other error);
whatever(); // - this will crash make the script die without calling the custom
error_handler
?
Edit this bug report at http://bugs.php.net/?id=12658edit=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 #12658 Updated: set_error_handler() not working properly (with 'Call to undefined function')
ID: 12658
Updated by: jmcastagnetto
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Analyzed
Bug Type: Scripting Engine problem
Operating System: Red Hat Linux, Win2000 sp2
PHP Version: 4.0.6
Old Assigned To: jmcastagnetto
Assigned To:
New Comment:
My mistake, did not understood the bug report correctly.
More testing shows that calls to undefined functions do
not generate an error level that can be catched by the error handling mechanism. Not
even when using:
error_reporting(E_ALL);
which just aborts execution of the script and gives the msg:
bFatal error/b: Call to undefined function: whatever() in bjunk.php/b on
line b24/bbr
whereas when using:
error_reporting(E_CORE);
just eats up the error (i.e. no fatal error msg is generated by the interpreter),
and the error handling function does not have time to do anything, so the script
aborts w/o any output.
Two issues need to be addressed:
1) The inconsitent behavior of E_CORE vs E_ALL (PHP 4.0.6), in view of the fact the
E_ALL includes E_CORE (as per Zend/zend_errors.h)
2) Whether is desirable to allow catching of fatal errors using the
set_error_handler() and error_reporting() functions
If the answer to (2) is no, then this should be clarified in the manual.
Previous Comments:
[2001-08-08 15:48:54] [EMAIL PROTECTED]
The assertion ... Seems that PHP cannot redirect 'Call to undefined function' errors
to a custom error
handler... is incorrect.
This seems to be a problem w/ the person reporting the bug *not* using the
error_reporting() function, as it is clearly noted in the manual example, changing the
code to read:
?php
define (ERROR,E_USER_WARNING);
define (WARNING,E_USER_NOTICE);
// set the error reporting level for this script
error_reporting (FATAL | ERROR | WARNING);
// Define a simple error handler
function error_handler ($level, $message, $file, $line, $context) {
echo An error of level $level was generated in file $file on line $line.
\nThe error message was: $message \nThe following variables were set in the
scope that the error occurred in: blockquote ;
print_r ($context);
print \n/blockquote;
}
// Set the error handler to the error_handler() function
set_error_handler ('error_handler');
trigger_error (Some other error);
whatever();
?
The output is:
An error of level 1024 was generated in file bugtest.php on line 20.
The error message was: Some other error
The following variables were set in the
scope that the error occurred in: blockquote
Array (
[PWD] = /tmp
[... snip ...]
[_] = /usr/local/bin/php
[PHP_SELF] =
[argv] = Array
(
[0] = bugtest.php
)
[argc] = 1
[HTTP_POST_VARS] = Array
(
)
[HTTP_GET_VARS] = Array
[...snip...]
/blockquote
This was tested with 4.0.6 on RH 7.1, more information is requested from the person
reporting the bug, before it is reclassified as bogus.
[2001-08-08 13:23:32] [EMAIL PROTECTED]
Seems that PHP cannot redirect 'Call to undefined function' errors to a custom error
handler...
A sample (taken partly from the manual):
pre
?php
// Define a simple error handler
function error_handler ($level, $message, $file, $line, $context) {
echo An error of level $level was generated in file $file on line $line. \nThe error
message was: $message \nThe following variables were set in the scope that the error
occurred in: blockquote ;
print_r ($context);
print \n/blockquote;
}
// Set the error handler to the error_handler() function
set_error_handler ('error_handler');
trigger_error (Some other error);
whatever(); // - this will crash make the script die without calling the custom
error_handler
?
Edit this bug report at http://bugs.php.net/?id=12658edit=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 #12658 Updated: set_error_handler() not working properly (with 'Call to undefined function')
ID: 12658
Updated by: jmcastagnetto
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Scripting Engine problem
Operating System: Red Hat Linux, Win2000 sp2
PHP Version: 4.0.6
New Comment:
Using:
error_reporting(E_ERROR);
does not work (same result as E_ALL), even though in Zend/zend_execute.c that is the
error level raised.
In Zend/zend.c the zend_error() function hands the error to zend_error_cb, which
points to one of the utility functions created during zend_startup() (called in
main/main.c)
I cannot track the chain down more, my C is very rusty.
Previous Comments:
[2001-08-08 16:18:00] [EMAIL PROTECTED]
My mistake, did not understood the bug report correctly.
More testing shows that calls to undefined functions do
not generate an error level that can be catched by the error handling mechanism. Not
even when using:
error_reporting(E_ALL);
which just aborts execution of the script and gives the msg:
bFatal error/b: Call to undefined function: whatever() in bjunk.php/b on
line b24/bbr
whereas when using:
error_reporting(E_CORE);
just eats up the error (i.e. no fatal error msg is generated by the interpreter),
and the error handling function does not have time to do anything, so the script
aborts w/o any output.
Two issues need to be addressed:
1) The inconsitent behavior of E_CORE vs E_ALL (PHP 4.0.6), in view of the fact the
E_ALL includes E_CORE (as per Zend/zend_errors.h)
2) Whether is desirable to allow catching of fatal errors using the
set_error_handler() and error_reporting() functions
If the answer to (2) is no, then this should be clarified in the manual.
[2001-08-08 15:48:54] [EMAIL PROTECTED]
The assertion ... Seems that PHP cannot redirect 'Call to undefined function' errors
to a custom error
handler... is incorrect.
This seems to be a problem w/ the person reporting the bug *not* using the
error_reporting() function, as it is clearly noted in the manual example, changing the
code to read:
?php
define (ERROR,E_USER_WARNING);
define (WARNING,E_USER_NOTICE);
// set the error reporting level for this script
error_reporting (FATAL | ERROR | WARNING);
// Define a simple error handler
function error_handler ($level, $message, $file, $line, $context) {
echo An error of level $level was generated in file $file on line $line.
\nThe error message was: $message \nThe following variables were set in the
scope that the error occurred in: blockquote ;
print_r ($context);
print \n/blockquote;
}
// Set the error handler to the error_handler() function
set_error_handler ('error_handler');
trigger_error (Some other error);
whatever();
?
The output is:
An error of level 1024 was generated in file bugtest.php on line 20.
The error message was: Some other error
The following variables were set in the
scope that the error occurred in: blockquote
Array (
[PWD] = /tmp
[... snip ...]
[_] = /usr/local/bin/php
[PHP_SELF] =
[argv] = Array
(
[0] = bugtest.php
)
[argc] = 1
[HTTP_POST_VARS] = Array
(
)
[HTTP_GET_VARS] = Array
[...snip...]
/blockquote
This was tested with 4.0.6 on RH 7.1, more information is requested from the person
reporting the bug, before it is reclassified as bogus.
[2001-08-08 13:23:32] [EMAIL PROTECTED]
Seems that PHP cannot redirect 'Call to undefined function' errors to a custom error
handler...
A sample (taken partly from the manual):
pre
?php
// Define a simple error handler
function error_handler ($level, $message, $file, $line, $context) {
echo An error of level $level was generated in file $file on line $line. \nThe error
message was: $message \nThe following variables were set in the scope that the error
occurred in: blockquote ;
print_r ($context);
print \n/blockquote;
}
// Set the error handler to the error_handler() function
set_error_handler ('error_handler');
trigger_error (Some other error);
whatever(); // - this will crash make the script die without calling the custom
error_handler
?
Edit this bug report at http://bugs.php.net/?id=12658edit=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 #12623 Updated: mod operator
ID: 12623
Updated by: jmcastagnetto
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Math related
Operating System: linux (suse)
PHP Version: 4.0.4pl1
New Comment:
The modulus operator is strictly defined for integer numbers, because it ...
basically just returns the remainder of an integer division operation ...
(paraphrasing from the KR book)
In this case the floats are truncated to integers and then the modulus operator is
applied, i.e.
203.5 turns into 203
17.9 turns into 17
then 203 % 17 = 16 (as expected)
Other languages follow this approach, while other round up the float previous to
operating on them, in those languages the result would be: 6
And other languages, like Java, have a third behavior in which when using floats, a
number of integer substractions is made and a floating point reminder is calculated,
see for example: http://softwaredev.earthweb.com/multi/article/0,,12079_630791,00.html
(explanation to question 3)
BTW, gawk also performs an integer number of substractions, if you try:
gawk '{ print (203.5 % 17.9) }'
you'll get 6.6
Bottomline, as this is an operator meant to work with integers, make the appropriate
conversion for the appropriate results, or implement a modulus function like:
function modulus_of ($q, $d) {
$rem = $q;
while ($rem $d )
$rem -= $d;
return $rem;
}
which *will* return 6.6 for floats, and should also work on integers.
Previous Comments:
[2001-08-07 11:14:21] [EMAIL PROTECTED]
Modulus (%) operator
i am not sure if the behavior for non-integer operands is defined, so i am not sure
how important this actually is
check
2035 % 179 = 66 // correct!
203.5 % 17.9 = 16// incorrect - should be 6.6!
?php
echo 2035 % 179 == . 2035 % 179;
echo br\n;
echo 203.5 % 17.9 == . 203.5 % 17.9;
?
Edit this bug report at http://bugs.php.net/?id=12623edit=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 #12155 Updated: modulus %
ID: 12155 Updated by: jmcastagnetto Reported By: [EMAIL PROTECTED] Old Status: Bogus Status: Closed Bug Type: Math related Operating System: linux 2.4.3 PHP Version: 4.0.5 New Comment: See Bug #12623 for a more complete explanation on modulus ( http://www.php.net/bugs.php?id=12623 ) Previous Comments: [2001-08-06 19:57:53] [EMAIL PROTECTED] float % int could lead to rounding difficulties, which is not a bug. [2001-07-13 20:34:11] [EMAIL PROTECTED] Integer limited to 204700 so there. [2001-07-13 18:29:23] [EMAIL PROTECTED] Appears to be broken on large(r) integers. Is this a limitation on the type used? (I am coding working ip2long/long2ip). $temp = 3194548456; print correct: . ($temp - 255*floor($temp/255)); print php: . $temp % 255 . br; as defined in maths, the % is equiv to MOD(n, d) = n - d*INT(n/d) where n is the number, d is the divisor. Edit this bug report at http://bugs.php.net/?id=12155edit=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 #10116 Updated: bcpow treats second argument as integer
ID: 10116 Updated by: jmcastagnetto Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: BC math related Operating System: Windows 98 PHP Version: 4.0.4pl1 New Comment: This is an issue w/ the bcmath library itself, not a PHP bug. If you look in ext/bcmath/libbcmath/src/raise.c you'll see that in the function bc_raise(), the exponent is coherced to a long, and the comments says: /* Raise NUM1 to the NUM2 power. The result is placed in RESULT. Maximum exponent is LONG_MAX. If a NUM2 is not an integer, only the integer part is used. */ Suggest submitting as a bug to the author of bcmath (if you think it is a bug): [EMAIL PROTECTED] Check also the definition of BC numbers in POSIX, the FAQ for bcmath, and the Unix/Linux command bc Previous Comments: [2001-04-02 09:29:49] [EMAIL PROTECTED] Function bcpow is supposed to work with arbitrary precision numbers. However, it seems to treat its second argument as an integer. E.g. echo bcpow(256,0.5); echo bcpow(256,0.99); both produce 1. It seems that the second argument is truncated down to integer value. Either this is a feature and documentation must be changed or it is a bug of either Windows version or even other versions of BCMath/PHP. bcpow(0.5,2); produces 0.25, which is all right. Regards, -- Dan Edit this bug report at http://bugs.php.net/?id=10116edit=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 #10116 Updated: bcpow treats second argument as integer
ID: 10116 Updated by: jmcastagnetto Reported By: [EMAIL PROTECTED] Old Status: Closed Status: Bogus Bug Type: BC math related Operating System: Windows 98 PHP Version: 4.0.4pl1 Previous Comments: [2001-04-02 09:29:49] [EMAIL PROTECTED] Function bcpow is supposed to work with arbitrary precision numbers. However, it seems to treat its second argument as an integer. E.g. echo bcpow(256,0.5); echo bcpow(256,0.99); both produce 1. It seems that the second argument is truncated down to integer value. Either this is a feature and documentation must be changed or it is a bug of either Windows version or even other versions of BCMath/PHP. bcpow(0.5,2); produces 0.25, which is all right. Regards, -- Dan Edit this bug report at http://bugs.php.net/?id=10116edit=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 #12623 Updated: mod operator
ID: 12623 Updated by: jmcastagnetto Reported By: [EMAIL PROTECTED] Old Status: Closed Status: Bogus Bug Type: Math related Operating System: linux (suse) PHP Version: 4.0.4pl1 Previous Comments: [2001-08-07 11:14:21] [EMAIL PROTECTED] Modulus (%) operator i am not sure if the behavior for non-integer operands is defined, so i am not sure how important this actually is check 2035 % 179 = 66 // correct! 203.5 % 17.9 = 16// incorrect - should be 6.6! ?php echo 2035 % 179 == . 2035 % 179; echo br\n; echo 203.5 % 17.9 == . 203.5 % 17.9; ? Edit this bug report at http://bugs.php.net/?id=12623edit=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 #12155 Updated: modulus %
ID: 12155 Updated by: jmcastagnetto Reported By: [EMAIL PROTECTED] Old Status: Closed Status: Bogus Bug Type: Math related Operating System: linux 2.4.3 PHP Version: 4.0.5 Previous Comments: [2001-08-06 19:57:53] [EMAIL PROTECTED] float % int could lead to rounding difficulties, which is not a bug. [2001-07-13 20:34:11] [EMAIL PROTECTED] Integer limited to 204700 so there. [2001-07-13 18:29:23] [EMAIL PROTECTED] Appears to be broken on large(r) integers. Is this a limitation on the type used? (I am coding working ip2long/long2ip). $temp = 3194548456; print correct: . ($temp - 255*floor($temp/255)); print php: . $temp % 255 . br; as defined in maths, the % is equiv to MOD(n, d) = n - d*INT(n/d) where n is the number, d is the divisor. Edit this bug report at http://bugs.php.net/?id=12155edit=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 #10166 Updated: read_exif_data loads whole image into memory
ID: 10166
Updated by: jmcastagnetto
Reported By: [EMAIL PROTECTED]
Old Status: Closed
Status: Bogus
Bug Type: *Graphics related
Operating System: Linux 2.2
PHP Version: 4.0 Latest CVS (04/04/2001)
Previous Comments:
[2001-07-30 13:03:01] [EMAIL PROTECTED]
In latest CVS there I have added an optional parameter
for read_exif_data():
proto read_exif_data(string filename [, int readall])
By setting 'readall' to 0 you can prevent it from
loading all of the file into memory.
Please test this.
--Jani
[2001-04-04 13:48:56] [EMAIL PROTECTED]
Some users observed that read_exif_data is too slow with 1MB image files, which is a
typical size for digital camera output. I looked into the implementation
(ext/exif/exif.c) and it looks like the whole compressed image data is always read
into memory, even though read_exif_data should be concerned with just the file header.
Here's a line from function read_exif_data:
PRE
ret = php_read_jpeg_exif(ImageInfo, (*p_name)-value.str.val,1);
/PRE
The last parameter (ReadAll=1), causes the whole image data loaded into memory inside
function scan_JPEG_header:
PRE
if (ReadAll) {
int cp, ep, size;
/* Determine how much file is left. */
cp = ftell(infile);
fseek(infile, 0, SEEK_END);
ep = ftell(infile);
fseek(infile, cp, SEEK_SET);
size = ep-cp;
Data = (uchar *)malloc(size);
if (Data == NULL) {
php_error(E_ERROR,could not allocate data for entire image);
}
got = fread(Data, 1, size, infile);
if (got != size) {
php_error(E_ERROR,could not read the rest of the image);
}
Sections[*SectionsRead].Data = Data;
Sections[*SectionsRead].Size = size;
Sections[*SectionsRead].Type = PSEUDO_IMAGE_MARKER;
(*SectionsRead)++;
/*
*HaveAll = 1;
*/
}
return TRUE;
/PRE
I believe the line above should be changed to feed 0 as value of parameter ReadAll.
Thanks.
V
Edit this bug report at http://bugs.php.net/?id=10166edit=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 #10166 Updated: read_exif_data loads whole image into memory
ID: 10166
Updated by: jmcastagnetto
Reported By: [EMAIL PROTECTED]
Old Status: Bogus
Status: Closed
Bug Type: *Graphics related
Operating System: Linux 2.2
PHP Version: 4.0 Latest CVS (04/04/2001)
New Comment:
Reclosed, edited wrong bug
Previous Comments:
[2001-08-03 21:56:04] [EMAIL PROTECTED]
Reopen if this isn't what you wanted.
[2001-07-30 13:03:01] [EMAIL PROTECTED]
In latest CVS there I have added an optional parameter
for read_exif_data():
proto read_exif_data(string filename [, int readall])
By setting 'readall' to 0 you can prevent it from
loading all of the file into memory.
Please test this.
--Jani
[2001-04-04 13:48:56] [EMAIL PROTECTED]
Some users observed that read_exif_data is too slow with 1MB image files, which is a
typical size for digital camera output. I looked into the implementation
(ext/exif/exif.c) and it looks like the whole compressed image data is always read
into memory, even though read_exif_data should be concerned with just the file header.
Here's a line from function read_exif_data:
PRE
ret = php_read_jpeg_exif(ImageInfo, (*p_name)-value.str.val,1);
/PRE
The last parameter (ReadAll=1), causes the whole image data loaded into memory inside
function scan_JPEG_header:
PRE
if (ReadAll) {
int cp, ep, size;
/* Determine how much file is left. */
cp = ftell(infile);
fseek(infile, 0, SEEK_END);
ep = ftell(infile);
fseek(infile, cp, SEEK_SET);
size = ep-cp;
Data = (uchar *)malloc(size);
if (Data == NULL) {
php_error(E_ERROR,could not allocate data for entire image);
}
got = fread(Data, 1, size, infile);
if (got != size) {
php_error(E_ERROR,could not read the rest of the image);
}
Sections[*SectionsRead].Data = Data;
Sections[*SectionsRead].Size = size;
Sections[*SectionsRead].Type = PSEUDO_IMAGE_MARKER;
(*SectionsRead)++;
/*
*HaveAll = 1;
*/
}
return TRUE;
/PRE
I believe the line above should be changed to feed 0 as value of parameter ReadAll.
Thanks.
V
Edit this bug report at http://bugs.php.net/?id=10166edit=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 #12505 Updated: array_sum function total calculate error
ID: 12505 Updated by: jmcastagnetto Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Arrays related Old Operating System: Red Hat Linux 7.1 Operating System: Red Hat Linux 6.1 Old PHP Version: 4.0.4pl1 PHP Version: latest CVS (08/01/01) New Comment: The problem is with the typecasting to LONG, if you use the code: ?php $tt=array(382478633.0,367687181.0,452504275.0,471367521.0,848270658.0,1181944543.0); echo array_sum($tt).\n; ? The result is the correct one (3704252811) Solution would be to 1) use floating point representation for bign numbers in PHP code (add caveat to the manual perhaps?) or 2) check that the array_sum result is nor overflowing LONG in the C code implementation and bump the type to DOUBLE if it does. second option would be better IMHO Previous Comments: [2001-08-01 04:02:52] [EMAIL PROTECTED] $tt=array(382478633,367687181,452504275,471367521,848270658,1181944543); $total_tt=array_sum($tt); echo Total_tt=.$total_tt; // Prints Total_tt=-590714485 Must be 3704252811. Edit this bug report at http://bugs.php.net/?id=12505edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #8106 Updated: array_pop problem when using against an array returned from a class
ID: 8106
Updated by: jmcastagnetto
Reported By: [EMAIL PROTECTED]
Old-Status: Analyzed
Status: Closed
Bug Type: Documentation problem
Assigned To:
Comments:
Fixed in manual (CVS)
Previous Comments:
---
[2000-12-07 03:13:01] [EMAIL PROTECTED]
Reclassified as documentation problem.
array_pop($arr) (and array_shift($arr) ?) returns NULL in case the $arr is
an empty array or it isn't an array at all.
--Jani
---
[2000-12-05 06:15:12] [EMAIL PROTECTED]
If you pass a non-array to array_pop() it just displays an
error message.
After checking the sources for this function, it looks
like it doesn't return anything in case of this error.
Do you mean it should return FALSE in case of this error?
(I think it should)
But if you pass an empty array for array_pop() it
won't return anything but will not display any error
messages either which I think is the right behaviour.
--Jani
---
[2000-12-04 21:10:00] [EMAIL PROTECTED]
Seems to return no TRUE value when using array_pop () on an array returned by a class.
Code Example:
?
class Form {
function parse ($arg) {
ereg("(.*)[(.?)]", $arg, $query);
return $query;
}
}
$form = new Form;
$output = $form-parse($QUERY_STRING);
$number = array_pop($output);
if ($number) { echo "$number exists"; }
foreach ($output as $tmp) {
if (($tmp)($tmp != $QUERY_STRING)) {
echo "$tmpBr";
}
}
?
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8106edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9338 Updated: in_array 'strict' parameter is not documented (properly)
ID: 9338 Updated by: jmcastagnetto Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Documentation problem Assigned To: Comments: From the manual: "If the third parameter strict is set to TRUE then the in_array() will also check the types of the needle in the haystack. " Previous Comments: --- [2001-02-19 12:26:34] [EMAIL PROTECTED] look at http://www.php.net/in_array that documentation should not help anyone understanding what 'strict' does --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9338edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #8266 Updated: Getting fatal error with xlst_process()
ID: 8266
Updated by: jmcastagnetto
Reported By: [EMAIL PROTECTED]
Old-Status: Assigned
Status: Closed
Bug Type: Documentation problem
Assigned To: sterling
Comments:
Fixed errors in example.
Previous Comments:
---
[2001-01-01 17:44:25] [EMAIL PROTECTED]
This is a manual bug. It will be fixed.
Try this with valid XSL and XML and you should get the appropriate results.
---
[2000-12-14 20:45:48] [EMAIL PROTECTED]
We've been having a lot of problems with this so please allow me to list in detail
what we've done so we can try and track down this bugger.
We did a virgin install of RedHat 6.2 with bare bones.
We downloaded the Sablotron 0.44 binaries and copied the libs to /usr/local/lib and
added /usr/local/lib to the /etc/ld.so.conf file and ran /sbin/ldconfig. We then
copied the contents of the include dir to /usr/local/include.
We downloaded the Apache 1.3.14 sources and did the typical ./configure in the apache
dir after untaring them.
We downloaded PHP 4.0.4RC6 (figured this was close enough to the latest CVS) and
untared it.
We ran ./configure --with-apache=../apache_1.3.14 --with-sablot --with-zlib
--enable-track-vars
We ran make. No problems. We ran make install and then compiled Apache using the
conventional ./configure --prefix=/www --activate-module=src/modules/php4/libphp4.a in
the apache dir. Ran make and then make install. We fixed the /www/conf/httpd.conf
file to work with php, of course. And started Apache with no problems up to this
point.
We used the following script:
?php
$xslData = '
xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xsl:template match="article"
table border="1" cellpadding="2" cellspacing="1"
tr
td width="20%"
/title
td width="80%"
h2xsl:value-of select="title"/h2
h3xsl:value-of select="author"/h3
br
xsl:value-of select="body"
/td
/tr
/table
/xsl:template
/xsl:stylesheet';
$xmlData = '
?xml version="1.0"?
article
titleLearning German/title
authorSterling Hughes/author
body
Essential phrases:
br
br
Komme sie mir sagen, woe die toilette es?br
Eine grande beer bitte!br
Noch einem bitte.br
/body
/article';
if (xslt_process($xslData, $xmlData, $result)) // This is line 42 BTW
{
echo "Here is the brilliant in-depth article on learning";
echo " German: ";
echo "brnbr";
echo $result;
}
else
{
echo "There was an error that occurred in the XSL transformation...n";
echo "tError number: " . xslt_errno() . "n";
echo "tError string: " . xslt_error() . "n";
exit;
}
?
If you'll notice it is the exact same script used in the xlst_process() example in the
PHP online docs.
With much anticipation after much effort, blood, sweat and tears... we got the
following error:
Fatal error: msgtype: error in /www/htdocs/index.php on line 42.
Attempting to execute any other xslt functions results in the same error.
I've tried a hundred different things and well I'm sick of compiling and compiling and
compiling and am frankly out of ideas. Can anyone fix this or tell me what I've done
wrong? Thanks.
Mike
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8266edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9202 Updated: Parse error when using terniary (?:) and unset()
ID: 9202 Updated by: jmcastagnetto Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Documentation problem Assigned To: Comments: Documentation fixed Previous Comments: --- [2001-02-09 22:45:12] [EMAIL PROTECTED] The documentation for Unset() states: Description int unset (mixed var [, mixed var [, ...]]) unset() destroys the specified variables and returns true. I have changed the type of this bug report to "Documentation Problem", since I have been informed that Unset is not a function. ? $avariable = "test"; $avariable=="test" ? $avariable .=" No problem with is_bool" : is_bool($avariable); $avariable=="test" ? $avariable .=" No problem with isset" : isset($avariable); $avariable=="test" ? $avariable .=" No problem with empty" : empty($avariable); $avariable=="test" ? $avariable .=" Problem with unset" : unset($avariable); echo $avariable; ? Output is Parse error: parse error in /home/httpd/html/mlr/unsetProblem.php on line 6 --- [2001-02-09 20:29:34] [EMAIL PROTECTED] ? $avariable = "test"; $avariable=="test" ? $avariable .=" No problem with is_bool" : is_bool($avariable); $avariable=="test" ? $avariable .=" No problem with isset" : isset($avariable); $avariable=="test" ? $avariable .=" No problem with empty" : empty($avariable); $avariable=="test" ? $avariable .=" Problem with unset" : unset($avariable); echo $avariable; ? Output is Parse error: parse error in /home/httpd/html/mlr/unsetProblem.php on line 6 --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9202edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9538 Updated: automatic extention of links fails with 'http://www...'
ID: 9538 Updated by: jmcastagnetto Reported By: [EMAIL PROTECTED] Old-Status: Analyzed Status: Closed Bug Type: Documentation problem Assigned To: Comments: Added note to the manual Previous Comments: --- [2001-03-03 17:11:03] [EMAIL PROTECTED] Yes, this is intented: We assume that non-relative URLs point to external sites and hence don't append the SID as it would be a security risk to leak the SID. - Sascha And for Sascha: Please update bug reports with the web interface. --Jani --- [2001-03-03 15:33:08] [EMAIL PROTECTED] Hi, the automatic extension of links works fine, except if I use links beginning with 'http://', where the SID will not be appended. If this is wanted, please insert it into the manual. thanks, Frank Loeffler --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9538edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9668 Updated: typo in foreach manual page
ID: 9668
Updated by: jmcastagnetto
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Documentation problem
Assigned To:
Comments:
This is fixed in CVS
Previous Comments:
---
[2001-03-10 04:15:52] [EMAIL PROTECTED]
From the foreach manual page:
/* foreach example 2: value (with key printed for illustration) */
$a = array (1, 2, 3, 17);
$i = 0; /* for illustrative purposes only */
foreach($a as $v) {
print "$a[$i] = $k.n";
}
-
that print statement should be
print "$a[$i] = $v.n";
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9668edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9641 Updated: get_required_files()/get_included_files() does not work as docuemented
ID: 9641
Updated by: jmcastagnetto
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Documentation problem
Assigned To:
Comments:
documentation updated to reflect new behavior
Previous Comments:
---
[2001-03-15 09:22:56] [EMAIL PROTECTED]
Now, get_required_files and get_included_files are the same.
Documentation should be changed.
---
[2001-03-08 18:26:48] [EMAIL PROTECTED]
get_required_files()/get_included_files() does not work as docuemented
http://www.php.net/manual/en/function.get-required-files.php
Tested under Apache 1.3.17 w/ mod-ssl, mod-gzip, and other modules comes with apache.
RedHat 7.0.1/j. PHP 4.0.4pl1 running as apache module.
I found strange require_once() behaviour (to be reported as bug) and I also found this
problem.
If this is not a script engine problem, then it should be documentation problem. Hope
this info helps developer/documentation team.
Following code is identical to the example in manual.
?php
require_once ('local.php');
require_once ('../inc/global.php');
for ($i=1; $i5; $i++) {
include_once 'util'.$i.'php';
}
echo 'pre';
echo "Required_once filesn";
print_r (get_required_files());
echo "Included_once filesn";
print_r (get_included_files());
echo date('H:i:s',time());
echo '/pre';
?
I get
===
Required_once files
Array
(
[0] = /home/httpd/httpd/html/untitled/local.php
[1] = /home/httpd/httpd/html/inc/global.php
[2] = /home/httpd/httpd/html/untitled/util1php
[3] = /home/httpd/httpd/html/untitled/util2php
[4] = /home/httpd/httpd/html/untitled/util3php
[5] = /home/httpd/httpd/html/untitled/util4php
)
Included_once files
Array
(
[0] = /home/httpd/httpd/html/untitled/local.php
[1] = /home/httpd/httpd/html/inc/global.php
[2] = /home/httpd/httpd/html/untitled/util1php
[3] = /home/httpd/httpd/html/untitled/util2php
[4] = /home/httpd/httpd/html/untitled/util3php
[5] = /home/httpd/httpd/html/untitled/util4php
)
08:17:35
===
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9641edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
