[PATCH] D48948: Fix raw_fd_ostream::write_impl hang due to an infinite loop with large output

[Zachary Turner via llvm-commits]

Ok, makes sense. Lgtm then
On Wed, Jul 11, 2018 at 8:18 AM Owen Reynolds via Phabricator <
reviews at reviews.llvm.org> wrote:

> gbreynoo added inline comments.
>
>
> ================
> Comment at: lib/Support/raw_ostream.cpp:617-618
> +#ifdef _WIN64
> +  // Windows write() requires signed 32 bit input so SIZE_MAX can not be
> used
> +  size_t MaxWriteSize = _I32_MAX;
> +#else
> ----------------
> zturner wrote:
> > Doesn't it actually require 32-bit unsigned input?
> >
> > https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/write
> >
> > ```
> > int _write(
> >    int fd,
> >    const void *buffer,
> >    unsigned int count
> > );
> > ```
> I'll clarify this in the comment above.
> Although the input type for _write is unsigned, the return type is signed
> ("-1" is returned in cases of an error). This is checked for in line 642.
> As the standard return of _write is to return how many bytes are written,
> in the case this value is larger than the signed max, the return value is a
> negative value. If the maximum unsigned value is written this will be -1
> and indicate an error.
>
> As the comment below states, windows _write is following POSIX as the
> behaviour for a write greater than SSIZE_MAX is implementation defined. I
> think it's best to keep to the portable behaviour below and not write
> anything windows specific to allow for a larger than SSIZE_MAX write.
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D48948
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180711/90a8bfb4/attachment.html>