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
At 18:16 01.12.99 +, you wrote:
On 30 Nov 1999 [EMAIL PROTECTED] wrote:
Geoff Thorpe [EMAIL PROTECTED] wrote:
great. BIO_nprintf?
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
"Geoff" == Geoff Thorpe [EMAIL PROTECTED] writes:
Geoff The whole point had been that snprintf (and vsnprintf) don't exist on all
Geoff platforms, they're GNU extensions. BIO_printf currently has a fixed 2k
Actually, they're in the new POSIX spec, but a buch of OS's still don't have
them.
--
Geoff Thorpe wrote:
There's a couple of people on this list who are also involved rather
heavily with Apache ... how do the licenses stand up to "code-sharing" of
that sort ... and if the answer is "badly", is there an alternative we
could pull in rather than leaving this as-is or having to
Hi there,
On Mon, 29 Nov 1999, Ben Laurie wrote:
Geoff Thorpe wrote:
There's a couple of people on this list who are also involved rather
heavily with Apache ... how do the licenses stand up to "code-sharing" of
that sort ... and if the answer is "badly", is there an alternative we
Hi there,
As I'd mentioned a while back, there seems to be some form of behavioural
change in the machinery underneath SSL_CTX_load_verify_locations that has
it spitting tacks where previously it was happy. As far as I can spot,
this affects ssltest, s_server, s_client, and four different parts
Geoff Thorpe wrote:
Hi there,
As I'd mentioned a while back, there seems to be some form of behavioural
change in the machinery underneath SSL_CTX_load_verify_locations that has
it spitting tacks where previously it was happy. As far as I can spot,
this affects ssltest, s_server,
