"brian m. carlson" writes:
> Yeah, that behavior is quite old. I'm surprised that Linux ever did
> that.
> ...
> I don't feel strongly either way. I feel confident the rest of Git
> doesn't use that field, so I don't see any downsides to keeping it other
> than the slight overhead of populating
On Wed, Oct 24, 2018 at 09:37:43AM +0200, Johannes Schindelin wrote:
> Hi brian,
>
> On Wed, 24 Oct 2018, brian m. carlson wrote:
> > These lines strike me as a bit odd. As far as I'm aware, Unix systems
> > don't return anything useful in this field when calling fstat on a pipe.
> > Is there a r
Hi brian,
On Wed, 24 Oct 2018, brian m. carlson wrote:
> On Tue, Oct 23, 2018 at 03:23:21AM -0700, Karsten Blees via GitGitGadget
> wrote:
> > - if (!get_file_info_by_handle(fh, buf))
> > + case FILE_TYPE_CHAR:
> > + case FILE_TYPE_PIPE:
> > + /* initialize stat fields */
> > +
On Tue, Oct 23, 2018 at 03:23:21AM -0700, Karsten Blees via GitGitGadget wrote:
> - if (!get_file_info_by_handle(fh, buf))
> + case FILE_TYPE_CHAR:
> + case FILE_TYPE_PIPE:
> + /* initialize stat fields */
> + memset(buf, 0, sizeof(*buf));
> + buf->st
From: Karsten Blees
fstat() is the only stat-related CRT function for which we don't have a
full replacement yet (and thus the only reason to stick with MSVCRT's
'struct stat' definition).
Fully implement fstat(), in preparation of implementing a POSIX 2013
compatible 'struct stat' with nanoseco
5 matches
Mail list logo
