In my pre-release testing of coreutils valgrind spotted a new problem.
Here's the fix I'll probably push soon.
>From 35cacf46fb3848941709955041c6902c7f6c20ca Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Wed, 18 Feb 2009 08:37:24 +0100
Subject: [PATCH] fts: avoid used-uninitialized error due
James Youngman wrote:
> I suggest
>
> dnl Prior to the 2009-01 updates, IBM C versions 9.0 and 10.1 support
> include_next when used
> dnl as the first preprocessor directive in a file, but not when it is
> preceded by another include
> dnl directive. To work around this, we include here.
> dnl
James Youngman wrote:
> What's the effect of the change? Merely a performance difference?
> Or is there a correctness issue?
"slight clarification"
The only possible influence on correctness would be if the
change affected how "nlinks" was calculated, since that's
the only place "is_dir" is us
The test-vc-list-files-cvs.sh self test appears to fail on minimal
debian lenny installations:
http://autobuild.josefsson.org/gnulib/log-200902170434329384000.txt
http://autobuild.josefsson.org/gnulib/log-2009021709042.txt
However it works on debian etch x86:
http://autobuild.josefsson.o
Jim Meyering writes:
> With the following patch, running this:
>
> /gnulib/gnulib-tool --create-testdir --with-tests --test fts-lgpl
>
> succeeds once again.
Great, works for me as well.
/Simon
On Sun, Feb 15, 2009 at 11:04 PM, Bruno Haible wrote:
> + dnl The include of is because IBM C 9.0, 10.1 (original
> + dnl versions, prior to 2009-01 updates) on AIX 6.1 supports include_next
> + dnl when used as first preprocessor directive in a file, but not when
> + dnl preceded
What's the effect of the change? Merely a performance difference?
Or is there a correctness issue?
