[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: ber_printf's return type in the C API



Mark,

There's a coding idion for sprintf() that looks something like this:

char* p = malloc( BIG_ENOUGH );

for( int i = 0; i < 10; i++ )
{
	p += sprintf( p, "%s %d", "foo", i );
}	

I'ts a concise way to effectively concatenate the results of several
sprintfs(). Given that ber_printf() returns -1 instead of 0 on error reduces
the utility of this scheme.

-gil

Gil Kirkpatrick
NetPro
"Kick it, Funky Snowman!" - Calef Brown

> -----Original Message-----
> From:	Hallvard B Furuseth [SMTP:h.b.furuseth@usit.uio.no]
> Sent:	Thursday, August 05, 1999 3:32 PM
> To:	Mark Smith
> Cc:	ietf-ldapext@netscape.com
> Subject:	Re: ber_printf's return type in the C API
> 
> Mark Smith writes:
> > Unless I missed it, the current draft only requires that "ber_printf()
> > returns -1 if there is an error during encoding and a positive number if
> > successful."  Therefore, it is okay to leave the return type as int.  Is
> > it important for the caller to know how many octets were output?
> 
> No, like I said: personally I don't care.
> 
> I was wondering if someone _else_ care, namely the people objected to
> giving ber_printf and ber_scanf the same way to report success/error
> because their used the returned values for something internally in their
> software.  (In fact, that may have been you Netscape people - I don't
> quite remember.)
> 
> -- 
> Hallvard