Way back on Sep 06, you wrote:
> IMHO, changing sort -V to produce more intuitively-correct results
> is the way to go
Well, as the author and contributor of the ``sort -V'' hack
I do have to agree. Since changing glibc is not happening,
I recommend using the putative verrevcmp() in sort(1) inst
Hi Ian. The GNU gnulib project is considering adding a function
that would compare strings in the same way that dpkg compares
version numbers, as you can see in the thread here:
http://permalink.gmane.org/gmane.comp.lib.gnulib.bugs/14693
Is there a chance that you would be willing to cont
Ben Pfaff wrote:
> Ian Jackson is the author and maintainer of other GNU software
> (GNU adns), so he might be willing to assign copyright to that
> function to the FSF. Have you asked him?
Would you care to ask him? (Not always me :-))
Bruno
Bruno Haible <[EMAIL PROTECTED]> writes:
>Kamil Dudka <[EMAIL PROTECTED]> writes:
>> There was something like "Copyright (C) 1995 Ian Jackson" in original file,
>> but also "... under terms of GNU General Public License..." I am not lawyer
>> and don't understand such details :-)
>
> So it's not
Eric Blake wrote on 2008-08-17:
> > One AC_SUBST line is redundant (already done in gl_SIGNAL_H_DEFAULTS). May I
> > remove it?
>
> For that matter, the HAVE_SIGACTION and HAVE_SIGINFO_T macros also look
> redundant in that file. Yes, go ahead and commit a cleanup.
The placement of the HAVE_STRU
Hi Kamil,
> New version of filevercmp.c is attached, now without copying of the input
> strings. I've also made a simple performance test - the speed was about 7-8x
> slower than original glibc strverscmp function, but the glibc's result is
> mostly wrong.
If you didn't get feedback from Jim,
Tom G. Christensen wrote:
> I grabbed this and tried to build it on Irix 5.3, 6.2 & 6.5(.30m).
> All 3 platforms report:
> checking for correct stack_t interpretation... no
Even IRIX 6.5?! Thanks for the info.
> cc-3316 cc: ERROR File = handler-unix.c, Line = 490
> The expression must be a poin
In message <[EMAIL PROTECTED]>, Eric Blake writes:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>According to Tom G. Christensen on 9/21/2008 2:30 PM:
>> cc-3316 cc: ERROR File = handler-unix.c, Line = 490
>> The expression must be a pointer to a complete object type.
>>
>> ss.ss_sp =
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Tom G. Christensen on 9/21/2008 2:30 PM:
> cc-3316 cc: ERROR File = handler-unix.c, Line = 490
> The expression must be a pointer to a complete object type.
>
> ss.ss_sp = extra_stack + extra_stack_size - sizeof (void *);
>
On Sun, Sep 21, 2008 at 04:03:54PM +0200, Bruno Haible wrote:
> Hi Eric,
>
> > Here's the minimal patch needed to CVS libsigsegv to expose the bug, as
> > well as work around it for Irix 5.3.
>
> Nice work! I'm applying this only slightly modified version.
> - In the configuration test, keep ro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding bug-gnulib, as this is an fts issue]
According to George Spelvin on 9/20/2008 3:36 PM:
> Looking for an inode that fsck complained about, I did a find,
> and noticed that it was statting every file name it found.
>
> Hunting through the code,
On Fri, Sep 12, 2008 at 06:53:49AM -0600, Eric Blake wrote:
> I'm committing this. It looks like your flavor of NetBSD now handles
> denormals, but still fails on negative zero.
I asked around a bit -- this was a regression. NetBSD has two versions
of this code around, and recently switched back
Paolo Bonzini wrote:
> Why not document "using the strdup module for the sake of replacing
> strdup is now obsolete", removing the dependency when POSIX behavior is
> not required
ok, why not?
> and calling strdup-posix just strdup?
IMO it does not hurt to keep the module 'strdup' around, for pa
Paolo Bonzini wrote:
> > Says the GCC 4.3.0 doc.
>
> My experience is different. In fact, in 4.4.0 it will even use it for
> instruction selection in some cases.
Then it's a doc bug. The GCC doc in svn (invoke.texi line 6589) says about the
effects of -fprofile-use:
The following options a
Hi Eric,
Eric Blake wrote:
> Actually, in the latest version of mingw, you have the option to use a
> more POSIX compliant [printf] instead of being stuck with MSVCRT's flaws:
> http://cygwin.com/ml/cygwin-announce/2008-09/msg8.html
Interesting... But I think gnulib should continue to be deve
Eric Blake wrote:
> > In the
> > 'double' case on mingw, in 'e' format, we need to use 3 digits for the
> > exponent, to match what MSVCRT does. This is not needed for 'long double' -
> > since 'long double' output is not supported by MSVCRT in the first place.)
>
> Actually, in the latest version
Bruno Haible wrote:
> Simon Josefsson wrote:
>> right now strdup doesn't make sure ENOMEM is supported, and it seems
>> unclear whether the modules that depend on strdup actually require that
>> behaviour from the strdup module. So as far as I can tell there is no
>> reason for the explicit depend
Bruno Haible wrote:
> Paolo Bonzini wrote:
>>> But the compiler does not know that fstrcmp is called millions of time and
>>> that this piece of code needs to be optimized for speed rather than for
>>> space.
>> If doing profile-directed optimization, it does know.
>
> Well, it _could_ know. But
Bruno Haible wrote:
> Paolo Bonzini wrote:
>>> But the compiler does not know that fstrcmp is called millions of time and
>>> that this piece of code needs to be optimized for speed rather than for
>>> space.
>> If doing profile-directed optimization, it does know.
>
> However, it is impractical:
Hi Eric,
> Here's the minimal patch needed to CVS libsigsegv to expose the bug, as
> well as work around it for Irix 5.3.
Nice work! I'm applying this only slightly modified version.
- In the configuration test, keep room to both sides of the ss_sp value.
On IRIX, we don't want the test to
Simon Josefsson wrote:
> right now strdup doesn't make sure ENOMEM is supported, and it seems
> unclear whether the modules that depend on strdup actually require that
> behaviour from the strdup module. So as far as I can tell there is no
> reason for the explicit dependency today.
At least one
On Sat, 20 Sep 2008, Eric Blake wrote:
According to Reuben Thomas on 9/20/2008 4:22 PM:
gnulib checks that the compiler supports #include_next before actually
stuffing #include_next into the generated .h files.
I think I might be confused here. I am running gnulib on my computer,
and distribu
Paolo Bonzini wrote:
> > But the compiler does not know that fstrcmp is called millions of time and
> > that this piece of code needs to be optimized for speed rather than for
> > space.
>
> If doing profile-directed optimization, it does know.
Well, it _could_ know. But currently, GCC exploits
Paolo Bonzini wrote:
> > But the compiler does not know that fstrcmp is called millions of time and
> > that this piece of code needs to be optimized for speed rather than for
> > space.
>
> If doing profile-directed optimization, it does know.
However, it is impractical: I never used profile-di
> But the compiler does not know that fstrcmp is called millions of time and
> that this piece of code needs to be optimized for speed rather than for space.
If doing profile-directed optimization, it does know. In this case, it
will even inline five or six recursive calls, as in
if (n >= 2)
25 matches
Mail list logo
