Dynamic diagnostics with new backend API

["Pierangelo Masarati" <ando@sys-net.it>]

Howard,

what about having SlapReply structure host
a "freeme" flag for the appropriate members
(I'm specifically thinking of rs_text) such
that we can dynamically allocate the diagnostics
to make them more expressive than generic
const strings when required?  This way, the
send_ldap_* func in charge of actually sending
the result may free them at will (and set it back
to NULL).

I understand that if not accurately handled
it may leak somewhere; we may require to
allocate it within a context, or have the
initiator of the request structure free it
at the end if none of the appropriate routines
used (and freed) it.

This way, most of the "Internal (implementation
specific) error (80)" messages would be accompanied
by more meaningful messages :)

Of course the same idea may be applied to other
fields (rs_entry, rs_refs) but I don't see it
much useful right now.  We may have a single flag,
e.g.

    unsigned int rs_flags;

// with a set of macros like

#define SR_FREE_TEXT    0x01
#define SR_FREE_REFS    0x02
#define SR_FREE_ENTRY   0x04

// and so on,

#define SLAPREPLY_MUST_FREE_TEXT(rs) ((rs)->sr_flags & SR_FREE_TEXT)
#define SLAPREPLY_SET_TEXT_FOR_FREE(rs) ((rs)->sr_flags |= SR_FREE_TEXT)
#define SLAPREPLY_UNSET_TEXT_FOR_FREE(rs) ((rs)->sr_flags &= ~SR_FREE_TEXT)
#define SLAPREPLY_FREE_TEXT(rs) \
    do { \
        if (SLAPREPLY_MUST_FREE_TEXT((rs))) { \
            free((rs)->sr_text); \
            (rs)->sr_text = NULL; \
            SLAPREPLY_UNSET_TEXT_FOR_FREE((rs)); \
    while (0)

and so on.  Comments?

Ando.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it