Ondřej Vašík wrote:
> > Does rpmvercmp have the above property?
>
> Similar. It separates name, epoch, version, release and architecture and
> compares those. Uses subsections of alphanum segments separated by
> non-alphanum chars. When same segment have different types, numeric is
> always consid
> I ran 'make syntax-check' (from gnulib's maint.mk) and it detected some
> problems in code in gnulib itself
These are not problems in the code. You better avoid to apply this coding
conventions checker against a file that is written with different coding
conventions.
Just a litt
Kamil Dudka wrote:
> I propose a simple patch for gnulib/strverscmp, which make this function much
> more useful.
We cannot take this patch, as the gnulib strverscmp function is meant to be
a substitute for the glibc function of the same name. (Sorry, the doc was not
clear about it until today.)
The gnulib documentation forgets to mention the 'strverscmp' gnulib module.
Fixing it like this:
2008-09-03 Bruno Haible <[EMAIL PROTECTED]>
* doc/glibc-functions/strverscmp.texi: Mention the strverscmp module.
*** doc/glibc-functions/strverscmp.texi.orig2008-09-04 00:44:04.0
Simon Josefsson wrote:
> Any objections to this patch?
Yes, I object.
Some people/projects prefer implicit conversions over explicit casts (e.g.
Paul, coreutils). Some people/projects prefer explicit casts over implicit
conversions (e.g. me, gettext). We've discussed this issue on this list
a few
Jim Meyering wrote:
> Other opinions welcome.
I mostly agree with Eric here: gnulib's substitute does not guarantee
that values stored in a 'bool' are either 0 or 1, therefore the code that
creates 'bool' values must guarantee it.
> The question is how best to *maintain* the precondition in
> the
I ran 'make syntax-check' (from gnulib's maint.mk) and it detected some
problems in code in gnulib itself, see:
./gl/error.c:152: wmessage = (wchar_t *) alloca (len * sizeof
(wchar_t));
./gl/vasnprintf.c:1482: buf = (TCHAR_T *) alloca (buf_neededlength * sizeof
(TCHAR_T));
maint.mk: do
[EMAIL PROTECTED] (Eric Blake) wrote:
>> > I'm referring to the use of the very same variables that are used in the
>> > patch. If those are not pure boolean then you have a bug anyway.
>>
>> Here are some of the changes needed to protect against the substandard
>> "bool" problem we're talking abo
I propose a simple patch for gnulib/strverscmp, which make this function much
more useful. Note that this patch is not related to any distribution. It just
cut off any postfix after version string.
Current version of coreutils uses strverscmp from gnulib, so if you want to
test this patch, you
> >
> > I'm referring to the use of the very same variables that are used in the
> > patch. If those are not pure boolean then you have a bug anyway.
>
> Here are some of the changes needed to protect against the substandard
> "bool" problem we're talking about. Some of the changes (& => &&)
> a
Ondřej Vašík <[EMAIL PROTECTED]> writes:
> Bruno Haible wrote:
>> Ondřej Vašík wrote:
>> > 3) to use/create different function for handling version sort (like
>> > rpmvercmp in recommended in glibc strverscmp() bugzilla)
>>
>> Does rpmvercmp have the above property?
>
> Similar. It separates nam
Bruno Haible wrote:
> Ondřej Vašík wrote:
> > 3) to use/create different function for handling version sort (like
> > rpmvercmp in recommended in glibc strverscmp() bugzilla)
>
> Does rpmvercmp have the above property?
Similar. It separates name, epoch, version, release and architecture and
comp
Ondřej Vašík wrote:
> as reported in RH bugzilla #253817
> (https://bugzilla.redhat.com/show_bug.cgi?id=253817), there is an issue
> with ls -v (and there will be same issue with sort -V soon). Problem is
> with sorting files with extensions or dist-tags (like .tar.gz)
> because .tar.gz is more tha
Hello,
as reported in RH bugzilla #253817
(https://bugzilla.redhat.com/show_bug.cgi?id=253817), there is an issue
with ls -v (and there will be same issue with sort -V soon). Problem is
with sorting files with extensions or dist-tags (like .tar.gz)
because .tar.gz is more than .1.tar.gz. Therefore
14 matches
Mail list logo
