Jim Meyering wrote:

>I don't thinks it's worthwhile to pander to single-threaded
>applications for something like this.
>  
>

In this case, pandering isn't very complicated, so I think I'll do it. 
Besides, this way, if anyone else is using the canon-host module, they
won't need to update callers after this change.

>I'd prefer a new, thread-safe interface.
>Maybe what we need is a new module, canon-host-r,
>that contains most of the current canon-host.c.
>Then canon-host.c could be rewritten as a wrapper
>around canon_host_r.
>  
>

This was about what I was thinking, though I was going to combine
canon_host & canon_host_r in the canon-host module and let the caller
decide what to call.  How about this API:

struct cherror_s
{
    enum {CH_GAI_ERROR, CH_HERROR} errtype;
    int errcode;
};

char *canon_host (char const *host);
char *canon_host_r (char const *host, struct cherror_s *cherror);

char *strcherror (void);
char *strcherror_r (struct cherror_s *cherror);


>But hey, if you're implementing it, your opinion counts
>for a lot :)
>  
>

:)

Derek

-- 
Derek R. Price
CVS Solutions Architect
Ximbiot <http://ximbiot.com>
v: +1 717.579.6168
f: +1 717.234.3125
<mailto:[EMAIL PROTECTED]>




_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Reply via email to