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

[Jim Meyering]

Pádraig Brady wrote:
> 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.

Agreed.  Thanks.