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

2009-10-06 Thread Paul Eggert
Pádraig Brady writes: > -human_readable (ST_NBLOCKS (f->stat), buf, human_output_opts, > -ST_NBLOCKSIZE, output_block_size)); > +! f->stat_ok ? "?" > +: human_readable (ST_NBLOCKS (f->stat), buf, human_output_opts, > +

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

2009-09-30 Thread 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 3edaa2363db0367e8fa472c4dc5c56

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

2009-09-30 Thread 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 20

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

2009-09-30 Thread Jim Meyering
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=A1dr

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

2009-09-30 Thread Pádraig Brady
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?= Date: Tue, 29 Sep 20

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

2009-09-29 Thread Jim Meyering
>From b7aaa0da8b47f4f373d3e0876bd540986278c6e2 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 29 Sep 2009 07:28:01 +0200 Subject: [PATCH] ls: don't use an undefined struct stat after failed stat/lstat MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding:

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

2009-09-29 Thread Jim Meyering
Eric Blake wrote: > According to Jim Meyering on 9/29/2009 5:13 AM: >> - /* The failed stat/lstat may have modified f->stat. Clear it, >> - since we may use at least its st_ino member, e.g., >> - when trying to print the inode of dangling symlink: >> -

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

2009-09-29 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 9/29/2009 5:13 AM: > - /* The failed stat/lstat may have modified f->stat. Clear it, > - since we may use at least its st_ino member, e.g., > - when trying to print the inode of dangling sy

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

2009-09-29 Thread Jim Meyering
; number, and other ways, it prints the inode of the dangling symlink. >> >> >>>From f7db178fdff1ebb113841035b55b103e074b5f6f Mon Sep 17 00:00:00 2001 >> From: Jim Meyering >> Date: Tue, 29 Sep 2009 07:28:01 +0200 >> Subject: [PATCH] ls: don't use an undefined str

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

2009-09-29 Thread Pádraig Brady
; >>From f7db178fdff1ebb113841035b55b103e074b5f6f Mon Sep 17 00:00:00 2001 > From: Jim Meyering > Date: Tue, 29 Sep 2009 07:28:01 +0200 > Subject: [PATCH] ls: don't use an undefined struct stat after failed > stat/lstat > > * src/ls.c (gobble_file): After a failed

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

2009-09-29 Thread Jim Meyering
Jim Meyering Date: Tue, 29 Sep 2009 07:28:01 +0200 Subject: [PATCH] ls: don't use an undefined struct stat after failed stat/lstat * src/ls.c (gobble_file): After a failed stat/lstat call, clear the f->stat buffer, since the syscall may have modified it, and we may need to know that stat.s