Re: ls -l bug with fileutils-4.1 on Mac OS X

[Jim Meyering]

Thanks a lot for the report and patch!
I've begun work to fix this a different way.
Here's what I'm doing:

A configure-time `run check' detects whether gettimeofday clobbers
that buffer, and if so, it arranges for programs to use gettimeofday
via a wrapper function that saves and restores the contents that
would have been clobbered. [some details omitted :-)]

That way, on systems with conforming implementations of gettimeofday,
programs like ls won't incur the cost of the extra copy.  Also, since
the work-around is only in configure and the wrapper function, we don't
have to inspect and maybe change every program that uses gettimeofday.
Actually, there will be a small change to each program that uses
gettimeofday, but it's an initialization (to get the location of the
clobbered buffer) that's run only on losing systems.

Jim

Bernhard Baehr <address@hidden> wrote:
...
> today I installed the GNU fileutils 4.1 on my Mac (Mac OS X 10.0.4,
> i. e. Darwin 1.3.7) to get color file lists. I found that for all
> kinds of long output of ls the first file in the output list was shown
> with the current date and time and not with the correct date and time
> from the files inode. The reason for this bug is that with Mac OS X
> gettimeofday() overwrites the global buffer thats address is returned
> by localtime(). But the ls output routine print_long_format() assumes
> that this global buffer remains intact. I´ve fixed the bug with the
> following patch for the source file ls.c.
...