Re: (ITS#4483) Confusion in freeing BerElement in abnormal conditions

[h.b.furuseth@usit.uio.no]

ando@sys-net.it writes:
> What if I add a set of macros like
> 
> LBER_FLUSH_FREE_NEVER		(0x0)
> LBER_FLUSH_FREE_ON_SUCCESS	(0x1)
> LBER_FLUSH_FREE_ON_ERROR	(0x2)
> LBER_FLUSH_FREE_ALWAYS		(LBER_FLUSH_FREE_ON_SUCCESS|LBER_FLUSH_FREE_ON_ERROR)
>
> ans use them consistently?  Code using 0 and 1 will use the default
> behavior (no matter if aware or not of its potential side effects) and
> behave as usual; fancy code that uses anything but 1 for "freeit" will
> behave unpredictably.

That's why I said "unlikely magic number" instead of 0,1,2,3 - to reduce
the chance of unpredictable behaviour.

And since the current implementation is buggy (does not follow the
manpage), we should aim for a future where the ber_flush(,,freeit=1)
does what the manpage says it does.

My suggestion is to make "free on success" the special case, but that
could be turned around - free on success unless the "free always" value
is given.

> Another option is to introduce a ber_flush2() function that uses the
> new interface, and make
> int
> ber_flush( Sockbuf *sb, BerElement *ber, int freeit )
> {
> 	return ber_flush2( sb, ber,
> 		freeit ? LBER_FLUSH_FREE_ON_SUCCESS
> 			: LBER_FLUSH_FREE_NEVER );
> }

-- 
Hallvard