[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