Re: [PHP-DEV] Memory leak
On Fri, 23 Jul 2004, George Schlossnagle wrote: > Sterling's not as tough as he looks. That's easy to say when you're 3,000 miles across the country. Then again, I know you're going to be together in Portland next week, so there's something for me to look forward to. :) -adam -- [EMAIL PROTECTED] author of o'reilly's "upgrading to php 5" and "php cookbook" avoid the holiday rush, buy your copies today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] time/001.phpt fix
Yep you're right. It can definitely return the same time twice in a row.
I'll commit this.
At 10:17 PM 7/23/2004 +0100, Joe Orton wrote:
[resend]
There's no reason why gettimeofday() shouldn''t return the same time in
successive calls; this test fails spuriously on Linux/x86_64 (which has
a particularly fast gettimeofday() implementation).
--- ext/standard/tests/time/001.phpt23 May 2003 20:56:33
- 1.4.2.2
+++ ext/standard/tests/time/001.phpt16 Jul 2004 12:50:13 -
@@ -17,7 +17,7 @@
for ($i=1;$i<=10;$i++) {
list($micro,$time)=explode(" ",microtime());
- if ($time > $last_t || ($time == $last_t && $micro > $last_m)) {
+ if ($time > $last_t || ($time == $last_t && $micro >= $last_m)) {
$passed++;
} else if ($failed++ <=10) {
$result .= sprintf('%06d', $i).": $time $micro < $last_t
$last_m\n";
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory leak
Sterling's not as tough as he looks. On Jul 23, 2004, at 5:05 PM, Ilia Alshanetsky wrote: Fine fine... let's rever it... I don't feel like carrying brass knuckles with me all the time. Ilia On July 23, 2004 04:36 pm, Andi Gutmans wrote: :) Ilia, you heard the man. I don't think he leaves you much choice unless you want to risk him waiting for you in a dark alley with a surprise :) Andi At 01:09 PM 7/23/2004 -0700, Sterling Hughes wrote: dooalocaaa, damnit On Fri, 23 Jul 2004 09:54:27 -0700, Andi Gutmans <[EMAIL PROTECTED]> wrote: At 12:51 PM 7/23/2004 -0400, Ilia Alshanetsky wrote: On July 23, 2004 12:40 pm, you wrote: At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote: On July 23, 2004 11:42 am, Andi Gutmans wrote: Why do we need one extra byte? We do not. Anyway, the question is if we should return to alloca() or not. I am slightly in favor but don't feel very strongly about it. Perhaps we could try a combination of the two, to ensure that no script is terminated due to a PHP crash if allocating on the stack fails. By default we can use alloca() if that fails to allocate the memory, we could use emalloc() and set a flag free code indicating which free function should be used. I'm hesitant to slow down the general case (even if it's just an additional if()) statement. I'd revert to alloca() and we can always add a --paranoid-stack-allocation directive to configure to use emalloc() :) The problem is that that this causes certain large script to just crash, without any meaningful information. Is the cost of 2 if()s really that pefromance prohibitive? No it's not. But 2 and 2 and 2 is :) I guess we can go with the if()'s for now Argh... Want to write a patch? Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- ..II.. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] fix symbol namespace pollution from bundled libgd
[resend, though I notice gd just got updated with some new functions so the symbol list is out of date. Feedback welcome on the principal of the change, anyway] Building the bundled libgd library into PHP causes symbol namespace pollution; if any other Apache modules link a different version of libgd into the Apache process they may instead pick up symbols from the PHP libgd, and segfault randomly. (One of our users saw this when using mod_perl with Perl::GD) The patch below (which applies to the 4.3 branch) fixes this with the same method used for the bundled expat and pcre libraries. The symbol list is painful to create because libgd doesn't consistently use a particular symbol prefix: I used the attached script after building a shared gd extension, as follows: nm -D .libs/gd.so | find-gdsyms.sh > syms.h Index: main/php_compat.h === RCS file: /repository/php-src/main/php_compat.h,v retrieving revision 1.11.4.5 diff -u -r1.11.4.5 php_compat.h --- main/php_compat.h 9 Aug 2003 14:26:40 - 1.11.4.5 +++ main/php_compat.h 16 Jul 2004 16:22:20 - @@ -107,6 +107,185 @@ #define XML_ParserReset php_XML_ParserReset #endif +#ifdef HAVE_GD_BUNDLED +#define any2eucjp php_gd_any2eucjp +#define createwbmp php_gd_createwbmp +#define empty_output_buffer php_gd_empty_output_buffer +#define fill_input_buffer php_gd_fill_input_buffer +#define freewbmp php_gd_freewbmp +#define gdAlphaBlend php_gd_gdAlphaBlend +#define gdCompareInt php_gd_gdCompareInt +#define gdCosT php_gd_gdCosT +#define gdDPExtractData php_gd_gdDPExtractData +#define gdFontGetGiant php_gd_gdFontGetGiant +#define gdFontGetLarge php_gd_gdFontGetLarge +#define gdFontGetMediumBold php_gd_gdFontGetMediumBold +#define gdFontGetSmall php_gd_gdFontGetSmall +#define gdFontGetTiny php_gd_gdFontGetTiny +#define gdFontGiant php_gd_gdFontGiant +#define gdFontGiantData php_gd_gdFontGiantData +#define gdFontGiantRep php_gd_gdFontGiantRep +#define gdFontLarge php_gd_gdFontLarge +#define gdFontLargeData php_gd_gdFontLargeData +#define gdFontLargeRep php_gd_gdFontLargeRep +#define gdFontMediumBold php_gd_gdFontMediumBold +#define gdFontMediumBoldData php_gd_gdFontMediumBoldData +#define gdFontMediumBoldRep php_gd_gdFontMediumBoldRep +#define gdFontSmall php_gd_gdFontSmall +#define gdFontSmallData php_gd_gdFontSmallData +#define gdFontSmallRep php_gd_gdFontSmallRep +#define gdFontTiny php_gd_gdFontTiny +#define gdFontTinyData php_gd_gdFontTinyData +#define gdFontTinyRep php_gd_gdFontTinyRep +#define gdGetBuf php_gd_gdGetBuf +#define gdGetByte php_gd_gdGetByte +#define gdGetC php_gd_gdGetC +#define _gdGetColors php_gd__gdGetColors +#define gd_getin php_gd_gd_getin +#define gdGetInt php_gd_gdGetInt +#define gdGetWord php_gd_gdGetWord +#define gdImageAABlend php_gd_gdImageAABlend +#define gdImageAALine php_gd_gdImageAALine +#define gdImageAlphaBlending php_gd_gdImageAlphaBlending +#define gdImageAntialias php_gd_gdImageAntialias +#define gdImageArc php_gd_gdImageArc +#define gdImageChar php_gd_gdImageChar +#define gdImageCharUp php_gd_gdImageCharUp +#define gdImageColorAllocate php_gd_gdImageColorAllocate +#define gdImageColorAllocateAlpha php_gd_gdImageColorAllocateAlpha +#define gdImageColorClosest php_gd_gdImageColorClosest +#define gdImageColorClosestAlpha php_gd_gdImageColorClosestAlpha +#define gdImageColorClosestHWB php_gd_gdImageColorClosestHWB +#define gdImageColorDeallocate php_gd_gdImageColorDeallocate +#define gdImageColorExact php_gd_gdImageColorExact +#define gdImageColorExactAlpha php_gd_gdImageColorExactAlpha +#define gdImageColorMatch php_gd_gdImageColorMatch +#define gdImageColorResolve php_gd_gdImageColorResolve +#define gdImageColorResolveAlpha php_gd_gdImageColorResolveAlpha +#define gdImageColorTransparent php_gd_gdImageColorTransparent +#define gdImageCompare php_gd_gdImageCompare +#define gdImageCopy php_gd_gdImageCopy +#define gdImageCopyMerge php_gd_gdImageCopyMerge +#define gdImageCopyMergeGray php_gd_gdImageCopyMergeGray +#define gdImageCopyResampled php_gd_gdImageCopyResampled +#define gdImageCopyResized php_gd_gdImageCopyResized +#define gdImageCreate php_gd_gdImageCreate +#define gdImageCreateFromGd php_gd_gdImageCreateFromGd +#define gdImageCreateFromGd2 php_gd_gdImageCreateFromGd2 +#define gdImageCreateFromGd2Ctx php_gd_gdImageCreateFromGd2Ctx +#define gdImageCreateFromGd2Part php_gd_gdImageCreateFromGd2Part +#define gdImageCreateFromGd2PartCtx php_gd_gdImageCreateFromGd2PartCtx +#define gdImageCreateFromGd2PartPtr php_gd_gdImageCreateFromGd2PartPtr +#define gdImageCreateFromGd2Ptr php_gd_gdImageCreateFromGd2Ptr +#define gdImageCreateFromGdCtx php_gd_gdImageCreateFromGdCtx +#define gdImageCreateFromGdPtr php_gd_gdImageCreateFromGdPtr +#define gdImageCreateFromGif php_gd_gdImageCreateFromGif +#define gdImageCreateFromGifCtx php_gd_gdImageCreateFromGifCtx +#define gdImageCreateFromGifSource php_gd_gdImageCreateFromGifSource +#define gdImageCreateFromJpeg php_
[PHP-DEV] [PATCH] time/001.phpt fix
[resend]
There's no reason why gettimeofday() shouldn''t return the same time in
successive calls; this test fails spuriously on Linux/x86_64 (which has
a particularly fast gettimeofday() implementation).
--- ext/standard/tests/time/001.phpt23 May 2003 20:56:33 - 1.4.2.2
+++ ext/standard/tests/time/001.phpt16 Jul 2004 12:50:13 -
@@ -17,7 +17,7 @@
for ($i=1;$i<=10;$i++) {
list($micro,$time)=explode(" ",microtime());
- if ($time > $last_t || ($time == $last_t && $micro > $last_m)) {
+ if ($time > $last_t || ($time == $last_t && $micro >= $last_m)) {
$passed++;
} else if ($failed++ <=10) {
$result .= sprintf('%06d', $i).": $time $micro < $last_t $last_m\n";
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory leak
Fine fine... let's rever it... I don't feel like carrying brass knuckles with me all the time. Ilia On July 23, 2004 04:36 pm, Andi Gutmans wrote: > :) > > Ilia, you heard the man. I don't think he leaves you much choice unless you > want to risk him waiting for you in a dark alley with a surprise :) > > Andi > > At 01:09 PM 7/23/2004 -0700, Sterling Hughes wrote: > >dooalocaaa, damnit > > > >On Fri, 23 Jul 2004 09:54:27 -0700, Andi Gutmans <[EMAIL PROTECTED]> wrote: > > > At 12:51 PM 7/23/2004 -0400, Ilia Alshanetsky wrote: > > > >On July 23, 2004 12:40 pm, you wrote: > > > > > At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote: > > > > > >On July 23, 2004 11:42 am, Andi Gutmans wrote: > > > > > > > Why do we need one extra byte? > > > > > > > > > > > >We do not. > > > > > > > > > > > > > Anyway, the question is if we should return to alloca() or not. > > > > I am > > > > > > > > > slightly in favor but don't feel very strongly about it. > > > > > > > > > > > >Perhaps we could try a combination of the two, to ensure that no > > > > script is > > > > > > > >terminated due to a PHP crash if allocating on the stack fails. By > > > > default > > > > > > > > we can use alloca() if that fails to allocate the memory, we > > > > could use > > > > > > > > emalloc() and set a flag free code indicating which free function > > > > should > > > > > > > > be used. > > > > > > > > > > I'm hesitant to slow down the general case (even if it's just an > > > > additional > > > > > > > if()) statement. I'd revert to alloca() and we can always add a > > > > > --paranoid-stack-allocation directive to configure to use emalloc() > > > > > :) > > > > > > > >The problem is that that this causes certain large script to just > > > > crash, without any meaningful information. Is the cost of 2 if()s > > > > really that pefromance prohibitive? > > > > > > No it's not. But 2 and 2 and 2 is :) > > > I guess we can go with the if()'s for now Argh... > > > Want to write a patch? > > > > > > > > > > > > Andi > > > > > > -- > > > PHP Internals - PHP Runtime Development Mailing List > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > >-- > >..II.. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory leak
:) Ilia, you heard the man. I don't think he leaves you much choice unless you want to risk him waiting for you in a dark alley with a surprise :) Andi At 01:09 PM 7/23/2004 -0700, Sterling Hughes wrote: dooalocaaa, damnit On Fri, 23 Jul 2004 09:54:27 -0700, Andi Gutmans <[EMAIL PROTECTED]> wrote: > At 12:51 PM 7/23/2004 -0400, Ilia Alshanetsky wrote: > >On July 23, 2004 12:40 pm, you wrote: > > > At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote: > > > >On July 23, 2004 11:42 am, Andi Gutmans wrote: > > > > > Why do we need one extra byte? > > > > > > > >We do not. > > > > > > > > > Anyway, the question is if we should return to alloca() or not. I am > > > > > slightly in favor but don't feel very strongly about it. > > > > > > > >Perhaps we could try a combination of the two, to ensure that no script is > > > >terminated due to a PHP crash if allocating on the stack fails. By default > > > > we can use alloca() if that fails to allocate the memory, we could use > > > > emalloc() and set a flag free code indicating which free function should > > > > be used. > > > > > > I'm hesitant to slow down the general case (even if it's just an additional > > > if()) statement. I'd revert to alloca() and we can always add a > > > --paranoid-stack-allocation directive to configure to use emalloc() :) > > > >The problem is that that this causes certain large script to just crash, > >without any meaningful information. Is the cost of 2 if()s really that > >pefromance prohibitive? > > No it's not. But 2 and 2 and 2 is :) > I guess we can go with the if()'s for now Argh... > Want to write a patch? > > > > Andi > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- ..II.. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory leak
dooalocaaa, damnit On Fri, 23 Jul 2004 09:54:27 -0700, Andi Gutmans <[EMAIL PROTECTED]> wrote: > At 12:51 PM 7/23/2004 -0400, Ilia Alshanetsky wrote: > >On July 23, 2004 12:40 pm, you wrote: > > > At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote: > > > >On July 23, 2004 11:42 am, Andi Gutmans wrote: > > > > > Why do we need one extra byte? > > > > > > > >We do not. > > > > > > > > > Anyway, the question is if we should return to alloca() or not. I am > > > > > slightly in favor but don't feel very strongly about it. > > > > > > > >Perhaps we could try a combination of the two, to ensure that no script is > > > >terminated due to a PHP crash if allocating on the stack fails. By default > > > > we can use alloca() if that fails to allocate the memory, we could use > > > > emalloc() and set a flag free code indicating which free function should > > > > be used. > > > > > > I'm hesitant to slow down the general case (even if it's just an additional > > > if()) statement. I'd revert to alloca() and we can always add a > > > --paranoid-stack-allocation directive to configure to use emalloc() :) > > > >The problem is that that this causes certain large script to just crash, > >without any meaningful information. Is the cost of 2 if()s really that > >pefromance prohibitive? > > No it's not. But 2 and 2 and 2 is :) > I guess we can go with the if()'s for now Argh... > Want to write a patch? > > > > Andi > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- ..II.. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory leak
message from marcus börger: "I have fixed the problem, without the need for an additional byte" regards, Lukas Smith aka Proxy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fp, rounding, decimal arithmetic - definitive account?
Hi George,
Although a bit long, your email was an interesting read.
I am not quite sure how we should approach this problem as PHP's FP has
gone through a zillion patches in the past few years. Adding another INI
option is always something I try and keep away from when possible.
As in general, I don't trust C floating point numbers, I do agree with
Christian's approach of using BC Math. It might be because we don't know
enough about it.
I'd like to hear what other people here think. If it's worth messing with
this code.
By the way, can you please post your code changes as unified diffs? We
can't go through the final code files and see what was changed.
Thanks,
Andi
At 02:19 PM 7/23/2004 +0300, George Whiffen wrote:
For the record, herewith:
- definitive (?) list of php's fp/rounding/arithmetic issues
- analysis of the issues
- discussion of options for handling the issues
- description of a comprehensive and "painless" solution
- links to and discussion of proof-of-concept C code
Apologies for the length of the post, but the subject matter is no more
suited to piece by piece discussion, than it is to piece
by piece resolution.
N.B. Throughout this post "decimal digits" refers to "significant
decimal figures", and should not be confused with "decimal places".
PHP FP/DECIMAL/ROUNDING ISSUES
==
A. General Arithmetic Errors
A1: Simple Decimal Arithmetic Failure
0.8 == 0.7 + 0.1 ==> false
A2: Composite Decimal Arithmetic Failure
print floor(8.2 - 0.2) ==> 7
A3: Difference Errors
print (0.5001 - 0.5) ==> 9.99989E-05
A4: Cumulative Arithmetic Errors
for ($i=1;$i<=100;++$i){$sum += 0.1;}print $sum ==> 10.0133
B. Intel (non-Win32) Specific Errors
B1: Round (unfixed by fuzziness)
Intel GNU with FUZZ: round(12345678.0255,3) ==>12345678.025
B2: Exact Arithmetic Errors
Intel GNU: 0.002877 == 2877/100 ==> false
B3: Round (fpu rounding twice)
Intel GNU with FUZZ: 0.002877 == round(0.002877,6) ==> false
B4: Round - inexact double - created by fuzziness
Intel GNU with FUZZ: round(0.94999,1) ==> 1.0
B5: Round - exact double - created by fuzziness
Intel GNU with FUZZ: round(144,-13) ==> 1.5e14
C. High Exponent Round Algorithm Failure
C1: Cross-Platform Rounding
Most (All?) Platforms: 1e-24 == round(1e-24,24) ==> false
C2: Platform Specific Variations
Intel GNU: 1e-23 == round(1e-23,23) ==> false
Win32: 1e-23 == round(1e-23,23) ==> true
Intel GNU: 5e-23 == round(5e-23,23) ==> true
Win32: 5e-23 = round(5e-23,23) ==> false
D. Inconsistent Rounding
round(0.255,2) ==> 0.26
sprintf("%.2f",0.255) ==> 0.25
ini_set('precision',2);print 0.255 ==> 0.26
round(0.235,2) ==> 0.24
sprintf("%.2f",0.235) ==> 0.23
ini_set('precision',2);print 0.235 ==> 0.23
C: printf("%.2f",0.245) ==> 0.24
php: printf("%.2f",0.245) ==> 0.25
E. Functional Limitations
-
E1: No half-even (bankers) rounding option
See Rasmus Lerdorf's comments on Bug #24142
E2: No round to precision
ANALYSIS
A. Arithmetic Errors
php implements its decimal arithmetic using C doubles, i.e. IEEE754
64bit binary representations. While the IEEE standard guarantees exact
binary arithmetic results within range and exactly rounded outside of
range, php's decimal arithmetic results are neither exactly rounded nor
exact within range.
C double representations of decimal numbers (e.g. 0.1) are typically
inexact. These "representation" errors, which only effect users of
C doubles for "other-base" arithmetic, can only be corrected by
rounding of the C double result in the appropriate base, base ten for
php. php does not do this, therefore arithmetic results may be in error.
Often the incorrect results are masked by subsequent implicit rounding
e.g. at output/string conversion. However, comparisons for equality,
(A1), integer conversions (A2) and difference operations (A3) can
reveal them immediately. If the results are used for further
arithmetic operations the errors can accumulate ad infinitum (A4).
The errors are strictly bounded. Even with maximal errors in
representation and an inexact final result, the returned result when
correctly rounded to 15 decimal digits will be the same as the true
decimal result, if it is of 15 digits or less. This is particularly
significant since 15 digits is the limit for consistent representation
of decimals by 64-bit binaries (C doubles). (Not all 16 decimal digit
numbers have distinct C double representations e.g. 0.9995
and 0.9994 have the same C double representation).
Therefore, with the addition of appropriate rounding, exact decimal
arithmetic to 15 significant figures is perfectly possible with php's
current fp implementation.
What is not possible, is exactly rounded decimal arithmetic, (the basic
IEEE854 requirement) which requires the result be calcula
Re: [PHP-DEV] [PATCH] two small typos in php.ini.* and mail.c
This should probably be applied but what if people are using them already? Any idea when these were introduced? Andi At 04:38 PM 7/23/2004 +0400, Antony Dovgal wrote: Hi all! Two small patches to fix typos in php.ini-dist, php.ini-recommended & mail.c These patches fix bug #29122. --- WBR, Antony Dovgal aka tony2001 [EMAIL PROTECTED] || [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory leak
At 12:51 PM 7/23/2004 -0400, Ilia Alshanetsky wrote: On July 23, 2004 12:40 pm, you wrote: > At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote: > >On July 23, 2004 11:42 am, Andi Gutmans wrote: > > > Why do we need one extra byte? > > > >We do not. > > > > > Anyway, the question is if we should return to alloca() or not. I am > > > slightly in favor but don't feel very strongly about it. > > > >Perhaps we could try a combination of the two, to ensure that no script is > >terminated due to a PHP crash if allocating on the stack fails. By default > > we can use alloca() if that fails to allocate the memory, we could use > > emalloc() and set a flag free code indicating which free function should > > be used. > > I'm hesitant to slow down the general case (even if it's just an additional > if()) statement. I'd revert to alloca() and we can always add a > --paranoid-stack-allocation directive to configure to use emalloc() :) The problem is that that this causes certain large script to just crash, without any meaningful information. Is the cost of 2 if()s really that pefromance prohibitive? No it's not. But 2 and 2 and 2 is :) I guess we can go with the if()'s for now Argh... Want to write a patch? Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory leak
On July 23, 2004 12:40 pm, you wrote: > At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote: > >On July 23, 2004 11:42 am, Andi Gutmans wrote: > > > Why do we need one extra byte? > > > >We do not. > > > > > Anyway, the question is if we should return to alloca() or not. I am > > > slightly in favor but don't feel very strongly about it. > > > >Perhaps we could try a combination of the two, to ensure that no script is > >terminated due to a PHP crash if allocating on the stack fails. By default > > we can use alloca() if that fails to allocate the memory, we could use > > emalloc() and set a flag free code indicating which free function should > > be used. > > I'm hesitant to slow down the general case (even if it's just an additional > if()) statement. I'd revert to alloca() and we can always add a > --paranoid-stack-allocation directive to configure to use emalloc() :) The problem is that that this causes certain large script to just crash, without any meaningful information. Is the cost of 2 if()s really that pefromance prohibitive? Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory leak
At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote: On July 23, 2004 11:42 am, Andi Gutmans wrote: > Why do we need one extra byte? We do not. > Anyway, the question is if we should return to alloca() or not. I am > slightly in favor but don't feel very strongly about it. Perhaps we could try a combination of the two, to ensure that no script is terminated due to a PHP crash if allocating on the stack fails. By default we can use alloca() if that fails to allocate the memory, we could use emalloc() and set a flag free code indicating which free function should be used. I'm hesitant to slow down the general case (even if it's just an additional if()) statement. I'd revert to alloca() and we can always add a --paranoid-stack-allocation directive to configure to use emalloc() :) Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Calling PHP functions from an extension
php5/Zend/zend_execute_API.c. It's quite simple. If you can't figure it out yourself, let me know. At 08:08 AM 7/23/2004 +0100, Lester Caine wrote: Andi Gutmans wrote: Check out zend_call_function(). It allows you to cache the function lookup in the fci_cache parameter. Where is the best place to find zend_call_function details, nothing in the manual and google gives some spurious results. -- Lester Caine - L.S.Caine Electronic Services -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory leak
On July 23, 2004 11:42 am, Andi Gutmans wrote: > Why do we need one extra byte? We do not. > Anyway, the question is if we should return to alloca() or not. I am > slightly in favor but don't feel very strongly about it. Perhaps we could try a combination of the two, to ensure that no script is terminated due to a PHP crash if allocating on the stack fails. By default we can use alloca() if that fails to allocate the memory, we could use emalloc() and set a flag free code indicating which free function should be used. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory leak
Why do we need one extra byte? Anyway, the question is if we should return to alloca() or not. I am slightly in favor but don't feel very strongly about it. Andi At 08:44 AM 7/23/2004 +0200, Marcus Boerger wrote: Hello Andi, the easiest way to make the test suit for 5.1 work again is to change zend_execute.c line 1352 to: EX(Ts) = (temp_variable *) safe_emalloc(sizeof(temp_variable), op_array->T, 1); notice the 1 instead of 0 which allocates one additional byte for every execution. regards marcus Thursday, July 22, 2004, 11:25:57 PM, you wrote: > The executor() change from alloca() to emalloc() seems to have introduced a > memory leak (found it with --enable-debug). Before I try and fix it, are we > reverting back to do_alloca(), free_alloca()? (even though we should see > why this memory leak is happening anyway because we don't always use > alloca() for do_allocat()). > Andi -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: fp, rounding, decimal arithmetic - definitive account?
Christian, You are paranoid! You don't need integers AND bc arithmetic! One or the other will do fine. C doubles are exact for integers a million times bigger than your requirements (i.e. over 1e15). That means that all integer calculations are also exact, even if php does store them as floats. If you really want non-integer results to be truncated (as with bc and zero scale), rather than approximated which is what the fp will do, then floor()/ceil() etc. will also work fine. Alternatively, you could have left your data with "cents" i.e. 2 decimal places and just used bc arithmetic and a scale of two or whatever you need for your sub-cent calculations. But if, as you say, you are really worried about a solution that works whatever your future customers do, then you definitely want php decimal arithmetic sorted out. Then you can handle multi-currencies without code changes. You don't have to care "where the decimal point goes" as long as there's no more than 15 digits altogether. George Christian Schneider wrote: Hey George, My point is: I'm not against improving accuracy of floating point arithmetic in PHP (although it could lead to some weird compatibility problems with older version) but I wouldn't advise people who really, really have to rely on their numbers to be correct to use floats anyway. George Whiffen wrote: > Exactly my point. When coding php you need floating point you can > trust or it is useless. As I said, bc is probably the best currently You can never trust floating point if you need both big numbers and precision at the same time. Floating point is always a trade off between the two. > If I'm wrong, and it's really only bc that can be trusted to add 0.1 > and 0.1, then shouldn't we be using that internally, rather than > pretending to have a useable fp decimal arithmetic? Floating point (even the current PHP implementation) is fine if you're happy enough with approximations which is the case 99% of the time. > P.S. I'm interested that you have money numbers so big that 15 digits > are not enough. It can't be gross world income which still isn't up I store cent values as integer strings and I possibly have to deal with values bigger than 214 million bucks (where PHP starts to convert ints to float) so I decided to go for BC Math. I didn't even care to check what the range/precision limits of floats are as I wanted something absolutely predictable, no matter what numbers are put into the system by our customers. Just because you're paranoid doesn't mean they're not after you :-) - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] two small typos in php.ini.* and mail.c
Hi all!
Two small patches to fix typos in php.ini-dist, php.ini-recommended &
mail.c
These patches fix bug #29122.
---
WBR,
Antony Dovgal aka tony2001
[EMAIL PROTECTED] || [EMAIL PROTECTED]
Index: ext/standard/mail.c
===
RCS file: /repository/php-src/ext/standard/mail.c,v
retrieving revision 1.82
diff -u -r1.82 mail.c
--- ext/standard/mail.c 9 Jan 2004 01:35:44 - 1.82
+++ ext/standard/mail.c 23 Jul 2004 12:30:07 -
@@ -86,7 +86,7 @@
char *subject=NULL, *extra_cmd=NULL;
int to_len, message_len, headers_len;
int subject_len, extra_cmd_len, i;
- char *force_extra_parameters = INI_STR("mail_force_extra_parameters");
+ char *force_extra_parameters = INI_STR("mail.force_extra_parameters");
char *to_r, *subject_r;
if (PG(safe_mode) && (ZEND_NUM_ARGS() == 5)) {
Index: php.ini-dist
===
RCS file: /repository/php-src/php.ini-dist,v
retrieving revision 1.215
diff -u -r1.215 php.ini-dist
--- php.ini-dist15 Jul 2004 19:09:37 - 1.215
+++ php.ini-dist23 Jul 2004 12:29:39 -
@@ -617,7 +617,7 @@
; Force the addition of the specified parameters to be passed as extra parameters
; to the sendmail binary. These parameters will always replace the value of
; the 5th parameter to mail(), even in safe mode.
-;mail.force_extra_paramaters =
+;mail.force_extra_parameters =
[SQL]
sql.safe_mode = Off
Index: php.ini-recommended
===
RCS file: /repository/php-src/php.ini-recommended,v
retrieving revision 1.159
diff -u -r1.159 php.ini-recommended
--- php.ini-recommended 15 Jul 2004 19:09:37 - 1.159
+++ php.ini-recommended 23 Jul 2004 12:29:39 -
@@ -675,7 +675,7 @@
; Force the addition of the specified parameters to be passed as extra parameters
; to the sendmail binary. These parameters will always replace the value of
; the 5th parameter to mail(), even in safe mode.
-;mail.force_extra_paramaters =
+;mail.force_extra_parameters =
[SQL]
sql.safe_mode = Off
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: fp, rounding, decimal arithmetic - definitive account?
Christian Schneider wrote: I store cent values as integer strings and I possibly have to deal with values bigger than 214 million bucks (where PHP starts to convert ints Errr, that's 21 million bucks where the transition occurs :-) - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: fp, rounding, decimal arithmetic - definitive account?
Hey George, My point is: I'm not against improving accuracy of floating point arithmetic in PHP (although it could lead to some weird compatibility problems with older version) but I wouldn't advise people who really, really have to rely on their numbers to be correct to use floats anyway. George Whiffen wrote: > Exactly my point. When coding php you need floating point you can > trust or it is useless. As I said, bc is probably the best currently You can never trust floating point if you need both big numbers and precision at the same time. Floating point is always a trade off between the two. > If I'm wrong, and it's really only bc that can be trusted to add 0.1 > and 0.1, then shouldn't we be using that internally, rather than > pretending to have a useable fp decimal arithmetic? Floating point (even the current PHP implementation) is fine if you're happy enough with approximations which is the case 99% of the time. > P.S. I'm interested that you have money numbers so big that 15 digits > are not enough. It can't be gross world income which still isn't up I store cent values as integer strings and I possibly have to deal with values bigger than 214 million bucks (where PHP starts to convert ints to float) so I decided to go for BC Math. I didn't even care to check what the range/precision limits of floats are as I wanted something absolutely predictable, no matter what numbers are put into the system by our customers. Just because you're paranoid doesn't mean they're not after you :-) - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: fp, rounding, decimal arithmetic - definitive account?
Christian Schneider wrote: George Whiffen wrote: As you either already know or could reasonably guess, my personal view is that simple, consistent, exact decimal arithmetic is highly desirable for any development tool intended for either novices or commercial use. I use BCMath for critical (e.g. money) calculations as I'd never trust floating point, with or without your fixes. Especially since I'm dealing with big numbers. - Chris Chris, Exactly my point. When coding php you need floating point you can trust or it is useless. As I said, bc is probably the best currently available approach. Presumably you trust bc because either you've checked the code yourself or you trust the guys who wrote it and say it works. So what we need with my fixes is for you to check the code/theory yourself or to have someone you trust to do it for you. So, who would you trust? If I'm wrong, and it's really only bc that can be trusted to add 0.1 and 0.1, then shouldn't we be using that internally, rather than pretending to have a useable fp decimal arithmetic? George P.S. I'm interested that you have money numbers so big that 15 digits are not enough. It can't be gross world income which still isn't up to $1e15 and certainly is never quoted to the dollar. I can only guess that it's global currency market volumes you are handling. Do they really quote them to the dollar? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: fp, rounding, decimal arithmetic - definitive account?
George Whiffen wrote: As you either already know or could reasonably guess, my personal view is that simple, consistent, exact decimal arithmetic is highly desirable for any development tool intended for either novices or commercial use. I use BCMath for critical (e.g. money) calculations as I'd never trust floating point, with or without your fixes. Especially since I'm dealing with big numbers. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Calling PHP functions from an extension
Andrey Hristov wrote: You can find some usage of this function in ext/standard/array.c Where is the best place to find zend_call_function details, nothing in the manual and google gives some spurious results. Ta - but I'll leave this to John :) It's a level below where I can usefully help at the moment, but since John can't support all the database types, I may need to delve deeper in the future. At present I don't have the tools in place to do my own builds of PHP, so I'll stick to areas where I can ;) -- Lester Caine - L.S.Caine Electronic Services -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Calling PHP functions from an extension
You can find some usage of this function in ext/standard/array.c hth, andrey Quoting Lester Caine <[EMAIL PROTECTED]>: > Andi Gutmans wrote: > > > Check out zend_call_function(). It allows you to cache the function > > lookup in the fci_cache parameter. > > Where is the best place to find zend_call_function details, nothing in > the manual and google gives some spurious results. > > -- > Lester Caine > - > L.S.Caine Electronic Services > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] make cli problems
# cvs -dPA # ./cvsclean # ./buildconf # ./configure ... Better choice: Use the snapshots.. --Jani On Fri, 23 Jul 2004, Wez Furlong wrote: >cvs -dP up >./buildconf >./configure > >On Fri, 23 Jul 2004 05:36:25 +, Curt Zirzow <[EMAIL PROTECTED]> wrote: >> >> >> I hope I'm doing something wrong, I'm issuing this: >> >> cvs -dP update >> make clean >> ./configure --with-zlib --and-other-options >> make cli >> >> My result when linking occurs: >> >> ext/zlib/zlib.lo: In function `zm_startup_zlib': >> /usr/home/curt/cvs/php/php-src/ext/zlib/zlib.c:212: undefined >> reference to `php_zlib_filter_factory' >> *** Error code 1 >> >> Stop in /usr/home/curt/cvs/php/php-src. >> >> Curt >> -- >> First, let me assure you that this is not one of those shady pyramid schemes >> you've been hearing about. No, sir. Our model is the trapezoid! >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > -- https://www.paypal.com/xclick/[EMAIL PROTECTED]&no_note=1&tax=0¤cy_code=EUR -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] fp, rounding, decimal arithmetic - definitive account?
For the record, herewith:
- definitive (?) list of php's fp/rounding/arithmetic issues
- analysis of the issues
- discussion of options for handling the issues
- description of a comprehensive and "painless" solution
- links to and discussion of proof-of-concept C code
Apologies for the length of the post, but the subject matter is
no more suited to piece by piece discussion, than it is to piece
by piece resolution.
N.B. Throughout this post "decimal digits" refers to "significant
decimal figures", and should not be confused with "decimal places".
PHP FP/DECIMAL/ROUNDING ISSUES
==
A. General Arithmetic Errors
A1: Simple Decimal Arithmetic Failure
0.8 == 0.7 + 0.1 ==> false
A2: Composite Decimal Arithmetic Failure
print floor(8.2 - 0.2) ==> 7
A3: Difference Errors
print (0.5001 - 0.5) ==> 9.99989E-05
A4: Cumulative Arithmetic Errors
for ($i=1;$i<=100;++$i){$sum += 0.1;}print $sum ==> 10.0133
B. Intel (non-Win32) Specific Errors
B1: Round (unfixed by fuzziness)
Intel GNU with FUZZ: round(12345678.0255,3) ==>12345678.025
B2: Exact Arithmetic Errors
Intel GNU: 0.002877 == 2877/100 ==> false
B3: Round (fpu rounding twice)
Intel GNU with FUZZ: 0.002877 == round(0.002877,6) ==> false
B4: Round - inexact double - created by fuzziness
Intel GNU with FUZZ: round(0.94999,1) ==> 1.0
B5: Round - exact double - created by fuzziness
Intel GNU with FUZZ: round(144,-13) ==> 1.5e14
C. High Exponent Round Algorithm Failure
C1: Cross-Platform Rounding
Most (All?) Platforms: 1e-24 == round(1e-24,24) ==> false
C2: Platform Specific Variations
Intel GNU: 1e-23 == round(1e-23,23) ==> false
Win32: 1e-23 == round(1e-23,23) ==> true
Intel GNU: 5e-23 == round(5e-23,23) ==> true
Win32: 5e-23 = round(5e-23,23) ==> false
D. Inconsistent Rounding
round(0.255,2) ==> 0.26
sprintf("%.2f",0.255) ==> 0.25
ini_set('precision',2);print 0.255 ==> 0.26
round(0.235,2) ==> 0.24
sprintf("%.2f",0.235) ==> 0.23
ini_set('precision',2);print 0.235 ==> 0.23
C: printf("%.2f",0.245) ==> 0.24
php: printf("%.2f",0.245) ==> 0.25
E. Functional Limitations
-
E1: No half-even (bankers) rounding option
See Rasmus Lerdorf's comments on Bug #24142
E2: No round to precision
ANALYSIS
A. Arithmetic Errors
php implements its decimal arithmetic using C doubles, i.e. IEEE754
64bit binary representations. While the IEEE standard guarantees
exact binary arithmetic results within range and exactly rounded
outside of range, php's decimal arithmetic results are neither
exactly rounded nor exact within range.
C double representations of decimal numbers (e.g. 0.1) are typically
inexact. These "representation" errors, which only effect users of
C doubles for "other-base" arithmetic, can only be corrected by
rounding of the C double result in the appropriate base, base ten for
php. php does not do this, therefore arithmetic results may be in error.
Often the incorrect results are masked by subsequent implicit rounding
e.g. at output/string conversion. However, comparisons for equality,
(A1), integer conversions (A2) and difference operations (A3) can
reveal them immediately. If the results are used for further
arithmetic operations the errors can accumulate ad infinitum (A4).
The errors are strictly bounded. Even with maximal errors in
representation and an inexact final result, the returned result when
correctly rounded to 15 decimal digits will be the same as the true
decimal result, if it is of 15 digits or less. This is particularly
significant since 15 digits is the limit for consistent representation
of decimals by 64-bit binaries (C doubles). (Not all 16 decimal digit
numbers have distinct C double representations e.g. 0.9995
and 0.9994 have the same C double representation).
Therefore, with the addition of appropriate rounding, exact decimal
arithmetic to 15 significant figures is perfectly possible with php's
current fp implementation.
What is not possible, is exactly rounded decimal arithmetic, (the basic
IEEE854 requirement) which requires the result be calculated to "infinite"
precision and rounded to the best approximation. Decimally rounded php
arithmetic can only guarantee that when the true result is
of 16 or more digits, the returned result after rounding may be either
the result immediately above or below the true result, but not
necessarily the closer of the two. Practically, exactly rounded
decimal fp arithmetic requires decimal fp hardware or complex and
slow multi-precision arithmetic.
For most php users, most of the time, exact arithmetic is quite good
enough. In particular, for money calculations, where exactness is
typically an overwhelming, and often legal, requirement, exactly
rounded results are largely irrelevant. Either calculations are simple
and
Re: [PHP-DEV] make cli problems
cvs -dP up ./buildconf ./configure On Fri, 23 Jul 2004 05:36:25 +, Curt Zirzow <[EMAIL PROTECTED]> wrote: > > > I hope I'm doing something wrong, I'm issuing this: > > cvs -dP update > make clean > ./configure --with-zlib --and-other-options > make cli > > My result when linking occurs: > > ext/zlib/zlib.lo: In function `zm_startup_zlib': > /usr/home/curt/cvs/php/php-src/ext/zlib/zlib.c:212: undefined > reference to `php_zlib_filter_factory' > *** Error code 1 > > Stop in /usr/home/curt/cvs/php/php-src. > > Curt > -- > First, let me assure you that this is not one of those shady pyramid schemes > you've been hearing about. No, sir. Our model is the trapezoid! > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Calling PHP functions from an extension
Use the source, Luke. On Fri, 23 Jul 2004 08:08:00 +0100, Lester Caine <[EMAIL PROTECTED]> wrote: > Andi Gutmans wrote: > > > Check out zend_call_function(). It allows you to cache the function > > lookup in the fci_cache parameter. > > Where is the best place to find zend_call_function details, nothing in > the manual and google gives some spurious results. > > > > -- > Lester Caine > - > L.S.Caine Electronic Services > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Calling PHP functions from an extension
Andi Gutmans wrote: Check out zend_call_function(). It allows you to cache the function lookup in the fci_cache parameter. Where is the best place to find zend_call_function details, nothing in the manual and google gives some spurious results. -- Lester Caine - L.S.Caine Electronic Services -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
