Bruno Haible <[EMAIL PROTECTED]> writes:

> Simon Josefsson wrote:
>> +const char *
>> +check_version (const char *req_version)
>> +{
>> +  if (!req_version || strverscmp (req_version, VERSION) < 0)
>> +    return VERSION;
>> +
>> +  return NULL;
>> +}
>> ...
>> You will typically wrap the call to the
>> `check_version' function through a library API, your library header
>> file may contain:
>> 
>>      #define STRINGPREP_VERSION "0.5.18"
>>      ...
>>        extern const char *stringprep_check_version (const char *req_version);
>> 
>>    The implementation of `stringprep_check_version' would simply pass
>> on the call to `check_version'.
>
> This makes it impossible to have more than one package using the check_version
> function. Say, stringprep and libiconv want to use the check_version
> function. On an ELF system, only one of the two copies of it can persist.
> Such that a call to stringprep_check_version would end up comparing with
> libiconv's version, or vice versa. And on non-ELF systems, you could get
> a linker error.

Ouch.  Thanks for the heads-up.

> I see only one way out: Recommend to use a config.h that does
>   #define stringprep_check_version check_version
> instead of a function that calls check_version.

I assume you meant:

#define check_version stringprep_check_version

Perhaps check_version.c could be compiled with
-Dcheck_version=$(PACKAGE)_check_version?  The gnulib module could set
something like that up, to avoid manual config.h additions.

Alternatively, check_version() could be modified to take the
PACKAGE_VERSION string as a parameter, passed on from
stringprep_check_version.  But then it is almost as easy to call
strverscmp directly in stringprep_check_version.

Perhaps using strverscmp directly is simpler, and we can forget about
this module.  I'm starting to lean towards that.  Unless you, or
anyone else, have any further ideas on this, I think I will forget
about this module.

Thanks,
Simon


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

Reply via email to