bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: check_version


From: Simon Josefsson
Subject: Re: check_version
Date: Thu, 14 Jul 2005 21:06:18 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

Bruno Haible <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]