Re: [PATCH] ls: don't use an undefined struct stat after failed stat/lstat

[Pádraig Brady]

Jim Meyering wrote:
> Pádraig Brady wrote:
>> Jim Meyering wrote:
>>> Thanks for the review.
>>> BTW, here's the merged version:
>> And attached one handles the `ls -Ls` case,
>> which I'll push soon.
>>
>> cheers,
>> Pádraig.
>> >From 3edaa2363db0367e8fa472c4dc5c5696537cde61 Mon Sep 17 00:00:00 2001
>> From: =?utf-8?q?P=C3=A1draig=20Brady?= <address@hidden>
>> Date: Tue, 29 Sep 2009 15:43:01 +0100
>> Subject: [PATCH] ls: always print "?" for allocated size of a dereferenced 
>> dangling symlink
>>
>> Previously for `ls -Ls` (but not `ls -Lsl`), we referenced
>> the st_blocks returned from the previous failed stat() call.
>> This undefined value was seen to be 0 for danglink symlinks at least.
>> * src/ls.c (print_file_name_and_frills, length_of_file_name_and_frills):
>> Don't use st_blocks if the previous stat() failed
>> * tests/ls/dangle: Add a test case
>> * NEWS: Mention the bug fix
> 
> Good catch.  Thanks!

The NEWS is getting a bit verbose on this minor issue.
Unless there are objections I'll roll up the NEWS from:

  ls -Li is now consistent with ls -Lil in printing "?", not "0" as the
  inode of a dangling symlink.

  ls -Li no longer relies on unspecified behavior of stat/lstat.
  Before this change, "ls -Li dangling-symlink" would mistakenly
  print the inode number of the symlink under some conditions.

  ls -Ls is now consistent with ls -Lsl in printing "?", not "0" as the
  allocated size of a dangling symlink.

to:

  ls -is is now consistent with ls -lis in ignoring values returned
  from a failed stat/lstat.  For example ls -Lis now prints "?", not "0",
  for the inode number and allocated size of a dereferenced dangling symlink.

cheers,
Pádraig.