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 refusing to use
other parts is generally pretty bad idea.
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.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115
--
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]
