Jim Meyering <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> wrote:
>> I'm using this module in all of my GNU packages. One complication
>> might be that it depends on VERSION being defined. Feedback
>> appreciated.
>
> Looks useful, but sounds like a job better implemented
> in a higher level language. But maybe you have constraints
> (portability?) that make this approach necessary.
Not sure I follow the higher-level language part... Perhaps I should
explain more what I use this for.
I use it in my libraries, which are all written in C. The source code
file, which assign a constant variable the value of VERSION (so the
version string end up in the .o), is compiled and installed, and
become part of libfoo.so. The application links with libfoo.so, and
uses foo.h during compile time. Inside foo.h, I place a copy of the
VERSION field, typically as:
#define STRINGPREP_VERSION "@PACKAGE_VERSION@"
Then the application can invoke:
#include <stringprep.h>
foo = stringprep_check_version (STRINGPREP_VERSION);
This has to uses:
1) To allow applications to retrieve the version number of the
libfoo.so (the version of foo.h is available via *_VERSION). This is
useful for diagnostic messages.
2) To detect when incompatible libraries/headers are used together.
Typical uses look like:
/* Check version of libgcrypt. */
if (!gcry_check_version (GCRYPT_VERSION))
die ("version mismatch\n");
> ...
>> Index: lib/check_version.c
> ...
>> +static const char *
>> +parse_version_number (const char *s, int *number)
>> +{
>> + int val = 0;
>> +
>> + if (*s == '0' && isdigit (s[1]))
>> + return NULL; /* leading zeros are not allowed */
>> +
>> + for (; isdigit (*s); s++)
>> + {
>> + val *= 10;
>> + val += *s - '0';
>> + }
>
> You might want to impose a limit (too arbitrary?) on the number
> of digits in each component, or add some other mechanism to
> protect against overflow. Otherwise, someone could conceivably
> provide a version number like 1.4294967297 that would satisfy
> a requirement for 1.1, or one like 1.4294967296 that would not.
>
> Also, that function treats non-numeric strings as zero
> and doesn't object (or provide a way for the caller to object)
> if there is something unexpected following a numeric component.
> If that is deliberate, you should add a comment saying so.
The intention isn't to be fool proof, it is just meant to catch simple
mistakes. I'll add a comment to that effect.
Thanks,
Simon
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
