vsnprintf vs vsprintf

[ron.i...@gmail.com]

Hello David, I have downloaded your package, it is very nice, I am
wanting to use this in a product where I work.

Here is the problem, our version of libc does not support vsnprintf
(it also does not support the regexp functions either). We are using
a cross-compiler of the GNU toolchain for LynxOS on PPC.

Question, I know you are using vsnprintf for the "printf" formatting
of your transfer buffer, and you are using the "n" to determine if you
have a buffer overflow so you can allocate a new buffer chunk.

Would it be possible to create a version with a compile time flag
where you can specify to use vsprintf instead (which our toolchain
does support). You can determine a buffer overflow condition by
setting up a buffer guardband, and if the current size of the data in
the buffer is within the guardband area, you know you need to do a
"realloc" and grab a new buffer chunk.

As for the regexp stuff, can you think of any other functions I can
use for that command line interpretation?

Thanks,
Regards,
Ron Iovine

[David Parrish]

I'd suggest patching in somebody else's implementation of vsnprintf, perhaps the ulibc one:

http://sources.busybox.net/index.py/trunk/uClibc/libc/stdio/vsnprintf.c?view=markup

Same suggestion for the regular expression library.

[ron.i...@gmail.com]

Thanks David, but I was able to hack on it and use vsprintf in place
of vsnprintf. From what I can tell, it looks like the contents of the
buffer is written to the client file descriptor for every cli_print/
cli_error call, as opposed to just having all the print calls in a
callback buffer their data, and then flushing the entire buffer when
the callback is complete. That makes a buffer overflow much less
likely, I increased the buffer size from 1k to 4k. Even though I am
using vsprintf, which has no overflow indication, this means that I
would need a single cli_printf call to exceed 4k, which is highly
unlikely in our scenario.

As for the regexp stuff, it looks like its used for filtering, which
we don't need either, so I just commented that stuff out. From my
testing, so far, I haven't found any problems, all the base
functionality that we need seems to be working, so it looks like I'm
good to go.

Thanks...

On Feb 22, 7:57 pm, David Parrish <dparr...@gmail.com> wrote:
> I'd suggest patching in somebody else's implementation of vsnprintf, perhaps

> the ulibc one:http://sources.busybox.net/index.py/trunk/uClibc/libc/stdio/vsnprintf...

>
> Same suggestion for the regular expression library.
>

> On Sat, Feb 21, 2009 at 1:37 PM, ron.iov...@gmail.com
> <ron.iov...@gmail.com>wrote: