Stanislav Malyshev [EMAIL PROTECTED] writes:
JG I disagree with this patch. The scenario of not being able to
JG allocate memory is a fatal error, and the only appropriate
JG response for php is to exit. If you need other behavior use
JG pemalloc( which calls malloc if set persistant ).
There's a big difference between an undefined behavior which may result in
a crash, and an organized shutdown. The former is dangerous, the latter is
not.
There are some parts of code that don't rely on this, from the times when
it wasn't true, but it doesn't cause any problem, so there's no
Zeev Suraski [EMAIL PROTECTED] writes:
There's a big difference between an undefined behavior which may
result in a crash, and an organized shutdown. The former is
dangerous, the latter is not.
[Sorry poor English follows]
I agree, but *who* is in charge to decide *what* an organized
WF Changing emalloc to return NULLs does not modify the program
WF behaviour: you (probably) receive a SIGSEGV from the emalloc
WF caller and the execution terminate. I can't see a big
Making such assumptions is a good way to security holes and obscure bugs.
--
Stanislav Malyshev, Zend
Stanislav Malyshev [EMAIL PROTECTED] writes:
[...]
WF I faced this problem using odbc with Solid. SQLColAttributes can
WF return very big number (2147483647) when you ask for
WF SQL_COLUMN_DISPLAY_SIZE of a LONG VARCHAR and obviously my computer
WF does not have enough virtual memory.
It
Zeev Suraski [EMAIL PROTECTED] writes:
At 12:38 29-08-01, Walter Franzini wrote:
Stanislav Malyshev [EMAIL PROTECTED] writes:
[...]
WF I faced this problem using odbc with Solid. SQLColAttributes can
WF return very big number (2147483647) when you ask for
WF SQL_COLUMN_DISPLAY_SIZE of
At 14:57 29-08-01, Walter Franzini wrote:
From the extension (the user of kernel services) pov I must disagree.
But obviusly I'missing something :-)
I don't see why there's a difference.
There may be a point in giving extension developers an _ex way to try and
allocate memory, and fail
Zeev Suraski [EMAIL PROTECTED] writes:
At 14:57 29-08-01, Walter Franzini wrote:
From the extension (the user of kernel services) pov I must disagree.
But obviusly I'missing something :-)
I don't see why there's a difference.
Maybe the difference is not ZE vs. extension but internal vs.
At 18:35 29-08-01, Walter Franzini wrote:
Zeev Suraski [EMAIL PROTECTED] writes:
At 14:57 29-08-01, Walter Franzini wrote:
From the extension (the user of kernel services) pov I must disagree.
But obviusly I'missing something :-)
I don't see why there's a difference.
Maybe the
At 18:45 29-08-01, George Schlossnagle wrote:
At 14:57 29-08-01, Walter Franzini wrote:
From the extension (the user of kernel services) pov I must disagree.
But obviusly I'missing something :-)
I don't see why there's a difference.
Maybe the difference is not ZE vs. extension
Hi,
is ok to send to this list patch for Zend?
I think _emalloc should not exit if unable to allocate enough memory,
malloc behave differently :-)
the patch below fix also a small problem with the format string.
--- php-4.0.6.ORIG/Zend/zend_alloc.cTue Jun 19 20:04:53 2001
+++
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 28, 2001 8:50 AM
Subject: [PHP-DEV] [PATCH] Zend/zend_alloc.c
Hi,
is ok to send to this list patch for Zend?
I think _emalloc should not exit if unable to allocate enough memory,
malloc behave differently :-)
the patch below fix
JG I disagree with this patch. The scenario of not being able to
JG allocate memory is a fatal error, and the only appropriate
JG response for php is to exit. If you need other behavior use
JG pemalloc( which calls malloc if set persistant ).
Actually, there's a lot of code in PHP that is based
--- php-4.0.6.ORIG/Zend/zend_alloc.c Tue Jun 19 20:04:53 2001
+++ php-4.0.6/Zend/zend_alloc.c Tue Jul 31 10:32:39 2001
@@ -158,12 +158,11 @@
HANDLE_BLOCK_INTERRUPTIONS();
if (!p) {
- fprintf(stderr,FATAL: emalloc(): Unable to allocate %ld bytes\n, (long) size);
+ fprintf(stderr,FATAL:
14 matches
Mail list logo
