hi, 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. -- Pierre 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
