On Wed, Mar 15, 2023 at 5:57 AM Michael Paquier <mich...@paquier.xyz> wrote:
> On Tue, Mar 14, 2023 at 01:26:27PM +0100, Juan José Santamaría Flecha
> wrote:
> > As highlighted in [1] fseek() might fail to error even when accessing
> > unseekable streams.
> >
> > PFA a patch that checks the file type before the actual fseek(), so only
> > supported calls are made.
>
> + * streams, so harden that funcion with our version.
> s/funcion/function/.
>
Done.
+extern int pgfseek64(FILE *stream, pgoff_t offset, int origin);
> +extern pgoff_t pgftell64(FILE *stream);
> +#define fseeko(stream, offset, origin) pgfseek64(stream, offset, origin)
> +#define ftello(stream) pgftell64(stream)
>
> What about naming the internal wrappers _pgfseeko64() and
> _pgftello64(), located in a new file named win32fseek.c? It may be
> possible that we would need a similar treatment for fseek(), in the
> future, though I don't see an issue why this would be needed now.
>
Done.
> + if (GetFileType((HANDLE) _get_osfhandle(_fileno(stream))) !=
> FILE_TYPE_DISK)
> + {
> + errno = ESPIPE;
> + return -1;
> + }
> Shouldn't there be cases where we should return EINVAL for some of the
> other types, like FILE_TYPE_REMOTE or FILE_TYPE_UNKNOWN? We should
> return ESPIPE only for FILE_TYPE_PIPE and FILE_TYPE_CHAR, then?
>
Done.
PFA a new version of the patch.
Regards,
Juan José Santamaría Flecha
v2-0001-fix-fseek-detection-of-unseekable-files-for-WIN32.patch
Description: Binary data
