On Tue, Nov 11, 2008 at 11:51 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote:

> This is extremely bad code. We have tons of better APIs to do what you
> want. And besides wouldn't it be better to list all those entries with
> enabled/disabled as table rows anyway?

I do not think adding a 30 lines table is better. About being an
extremely bad code, in which way? What will you use then? Each of
these features or protocols are present or not. The maximum size is
known and the buffer is large enough to contain them.

> (spprintf, snprintf, strcat, smart-strings,...)

> (the problem is that adding something will mostlikely result in crashes as
> ppl will add the necessary three lines and be happy because something else
> is disabled for them. Then someone having all enabled gets crashes because
> they forgot to increase the size of the string.

The problem is you do not know before hand which features are enabled.
As I agree that dynamic allocation for the protocols string would be
better, there is no need to use it now or in the mid term. The size of
the tmp buffer is large enough to support much more protocols than
curl or features can ever have.

One thing I forgot to add is to check if n > buffer size, it will
solve the problem you are refering to.


http://blog.thepimp.net | http://www.libgd.org

PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to