Daniel,

I'm in violent agreement with both of your points. Thus my original
description of my change as a hack.

There's no problem reducing MAX_PARAMETERS to something much lower (like
16). That reduces the stack load on my platform with a single recursion to
under 1K. However, there's no checking in dprintf_Pass1() to ensure that
the MAX_PARAMETERS limit is not exceeded. (Surely why MAX_PARAMETERS was set
to the insane level of 128.) There's one case in http.c where add_bufferf()
is now invoked with 14 format fields, so the potential exists for overrun.

I'm willing to pursue a consensus course of action and test the changes on
my platform. Fire away.

Cheers

-----Original Message-----
From: Daniel Stenberg [mailto:daniel_at_haxx.se]
Sent: Saturday, July 29, 2006 2:21 PM
To: libcurl development
Subject: mprintf MAX_PARAMETERS (was RE: Stack smashed when linked
withpthreads)

On Fri, 28 Jul 2006, Gary Maxwell wrote:

> Well, going back and looking at the change, the hack wasn't as extensive
as
> I remembered. This patch is generated off the current CVS tree:

Thanks for posting this, I can't see anything wrong with this patch, but the

need for it made me think:

1 - its a pity having to do two malloc()s in such a lowlevel function as
they
     are bound to make this function MUCH slower and thus slow down lots of
     operations that use *printf() functions.

2 - MAX_PARAMETERS is currently set to 128 which is insanely much and
nothing
     in curl or libcurl is anywhere near this limit. The *printf() functions
     are already marked for getting removed from the public API in a future
     version so I think getting this limit more adjusted to libcurl usage
makes
     lots of sense... I can't see any reason why we should support more than
16
     parameters.

If we'd lower the limit to 16, would the patch really still be need or
wanted?

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html