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 n
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.
>
>
> > 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. external
> data, where
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 interna
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 grace
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>>
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 a LONG VARCHAR and obvio
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
WF>> When emalloc fails to allocate ZEND INTERNAL MEMORY the current
WF>> behaviour is correct, but what if the author of an EXTENSION has a
WF>> different idea?
Then the author of the extension doesn't use Zend APIs. API is the certain
way of defining the behaviour. Using part of the API while r
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 P
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 s
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 r
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 persi
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
nzini" <[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,
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
+++ php-4.0.6/Z
--- 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:
17 matches
Mail list logo
