On 30 Nov 1999 [EMAIL PROTECTED] wrote:
> Geoff Thorpe <[EMAIL PROTECTED]> wrote:
> > great. BIO_nprintf?
>
> BIO_nprintf() wouldn't be of much use in itself, would it?
>
> Better to just fix BIO_printf so it handles unlimited length output
> the way printf() does. Fixing it right will mean including source
> for a printf() implementation, modified to write to a BIO instead of
> the stdout FILE. If that's too much then simply using vsnprintf()
> and a malloced buffer might do as well.
The whole point had been that snprintf (and vsnprintf) don't exist on all
platforms, they're GNU extensions. BIO_printf currently has a fixed 2k
buffer (see crypto/bio/b_print.c) ... if we can obtain portable snprintf
code then a buffer-safe BIO_??printf?? function could be introduced.
Mallocing, freeing and remallocing is something many aren't happy to do -
so I think an snprintf-style function (where you provide the buffer and
buffer-size as arguments) would be preferable to an all-singing
all-dancing dynamic BIO_printf that handles anything.
But this would require a new function as the argument list would differ
from BIO_printf.
Cheers,
Geoff
----------------------------------------------------------------------
Geoff Thorpe Email: [EMAIL PROTECTED]
Cryptographic Software Engineer, C2Net Europe http://www.int.c2.net
----------------------------------------------------------------------
May I just take this opportunity to say that of all the people I have
EVER emailed, you are definitely one of them.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
