Updated draft for kadmind plugin API

[Henry B. Hotz]

I dislike complicating an API with "trivial" overhead functions, like  
special-purpose versions of free().  It's a forrest-for-trees, kind  
of thing.  If we can't leave it as-is, can't we just declare that you  
use the standard system malloc()/free() routines?

On Apr 23, 2007, at 1:31 PM, krbdev-request at mit.edu wrote:

> Date: Mon, 23 Apr 2007 14:54:22 -0500
> From: Nicolas Williams <Nicolas.Williams at sun.com>
> Subject: Re: Updated draft for kadmind plugin API
> To: Russ Allbery <rra at stanford.edu>
> Cc: krbdev at mit.edu
> Message-ID: <20070423195420.GC16381 at Sun.COM>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, Apr 23, 2007 at 11:37:01AM -0700, Russ Allbery wrote:
>> Nicolas Williams <Nicolas.Williams at sun.com> writes:
>>> On Sat, Apr 21, 2007 at 03:25:12PM -0700, Russ Allbery wrote:
>>
>>>>           krb5_error_code (*check)(void *, krb5_principal,
>>>>                                    const char *password,
>>>>                                    char *errstr, int errstrlen);
>>>                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>> I'd rather have the module output a pointer to a string and that the
>>> caller have to call a module function to release it.  Else the  
>>> caller
>>> has to have code to do the buffer realloc dance -- ugh.
>>
>> My intention was actually to just use BUFSIZ or something similar  
>> and let
>> the message get truncated, since I didn't see a lot of need to put
>> arbitrary long data into the error message.  But maybe this is
>> short-sighted of me?
>>
>> With the update plugin, one *cannot* do the realloc dance since  
>> calling
>> the function multiple times repeats the operation.
>
> Well, I imagined that perhaps the plugin invocation would be  
> idempotent
> if the ersstrlen was too short, but even so it's icky.
>
>> Would people rather see a char **errstr and a new error_free hook  
>> for both
>> modules?
>
> I would :)