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 obviously my computer
> > WF>> does not have enough virtual memory.
> >
> > It is not always a wise idea to use MAX_SIZE kind of constants to allocate
> > memory. Some of them can indeed be huge. You should fix you code to not
> > use such constants for memory allocation.
>
>If you look better at the patch, the current php implementation
>(php-4.0.6 and current cvs) uses the MAX_SIZE approach and I try to
>lower this number to a more reasonable value.
I'm not sure what you mean here. Several things:
- A crash is not an organized shutdown, no matter how you look at
it. Different operating systems treat it in different ways, and none of
them is considered a good way of shutting down.
- By default, PHP builds without memory_limit enabled. A failure would
only occur if we actually run out of memory, and then, simply put, we're
screwed anyway, and the best thing we can do is try to shut down as nicely
as possible.
- If you enable memory_limit, when the program reaches it, the engine
schedules a shutdown - a very organized one. The only situation in which an
exit() would occur is if during the shutdown, the memory consumption
continues to grow beyond 1MB of the memory limit.
Zeev
--
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]
