At 12:38 29-08-01, Walter Franzini wrote:
Stanislav Malyshev <stas@zend.com> 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