[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?