[Rpm-maint] [PATCH 2/2] Recognize "<epoch>:" as a part of a label (ticket #117)

[Ales Kozumplik]

On 11/15/2011 10:37 AM, Panu Matilainen wrote:
>> /** \ingroup dbi
>> + * Return (newly allocated) integer of the epoch.
>> + * @param s version string optionally containing epoch number
>> + * @retval version only the version part of s
>> + * @return newly allocated epoch integer
>> + */
>> +static int * splitEpoch(const char *s, const char **version)
>> +{
>> + int e;
>> + int *epoch = NULL;
>> + char *end;
>> +
>> + *version = s;
>> +
>> + e = strtol(s,&end, 10);
>> + if (*end == ':') {
>> + *version = end + 1;
>> + epoch = rmalloc(sizeof(*epoch));
>> + *epoch = e;
>> + }
>> + return epoch;
>> +}
>
> Why the malloc? AFAICS you could just have "int epoch = 0" in
> dbiFindByLabel() and pass the pointer to that to splitEpoch(), only
> changing the value if one was actually found, equaling the "no epoch
> equals zero epoch" behavior and avoiding couple seemingly unnecessary
> malloc/free on what's a fairly busy path.
>

Hm,

What about this perl example:

$ rpm -qa --queryformat="%{NEVRA}\n"|grep perl
..
perl-4:5.14.2-190.fc16.x86_64
..

So, perl has epoch 4. However the current implementation from the patch 
does not in fact treat no epoch as zero epoch, so

$ rpm -q perl-5.14.2
perl-5.14.2-190.fc16.x86_64

correctly finds the package, just as

$ rpm -q perl-4:5.14.2
perl-5.14.2-190.fc16.x86_64

does. So we can not use a simple integer, we need splitEpoch() to be 
able to return a 'no-epoch' value that says 'we dont care what the epoch 
is' and so this value has to be different from 0. I am not saying it's 
not possible to save us the malloc, it will just be bumpy. Maybe I could 
use -1 for no epoch?

Ales