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

RE: ber_printf's return type in the C API



Mark,

I think when I've seen this kind of coding, error checking was not high on
the developer's list of priorities. <g> 

Given that the state is maintained in the ber cookie, you are right,
returning byte counts to walk through the output buffer isn't needed.

-gil

> -----Original Message-----
> From:	mcs@netscape.com [SMTP:mcs@netscape.com]
> Sent:	Friday, August 06, 1999 7:43 AM
> To:	Gil Kirkpatrick
> Cc:	'Hallvard B Furuseth'; ietf-ldapext@netscape.com
> Subject:	Re: ber_printf's return type in the C API
> 
> Gil Kirkpatrick wrote:
> > 
> > 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.
> 
> I am not sure why it would help much to return 0 instead of -1 on error
> (you still need to check for errors, right?).  Anyway, you don't need to
> implement a scheme like this with ber_printf() because the current
> encoding position and all of the details of memory allocation, etc. are
> handled internally by the API implementation.  You can just do something
> like this:
> 
>     BerElement *ber = ber_alloc_t( LBER_USE_DER );
>     if ( NULL == ber ) {
>         return( -1 );		/* allocation error */
>     } else {
>         for ( int i = 0; i < 10; i++ ) {
>             if ( ber_printf( ber, "si", "foo", i ) == -1 ) {
>                 ber_free( ber, 1 );
>                 return( -1 );   /* encoding error  */
>             }
>         }
>     }
>     ...
> 
> -- 
> Mark Smith
> iPlanet Directory Architect / Sun-Netscape Alliance
> My words are my own, not my employer's.   Got LDAP?