[Lldb-commits] [PATCH] D28305: [Host] Handle short reads and writes, take 3

Zachary Turner via lldb-commits lldb-commits at lists.llvm.org
Wed Jan 4 14:07:09 PST 2017

Honestly I would just assume we blanket kill FILE* across the entire
codebase.  It's non-portable, doesn't interoperate with Python 3, doesn't
interoperate with C++ library facilities, and is clunky to deal with on
Windows since most of the useful APIs won't accept one.

On Wed, Jan 4, 2017 at 2:04 PM Greg Clayton via Phabricator <
reviews at reviews.llvm.org> wrote:

> clayborg added a comment.
> In https://reviews.llvm.org/D28305#635877, @labath wrote:
> > The way this deals with it is by using `GetDescriptor()` which extracts
> the raw fd from FILE *, and then always deals with those. I guess this has
> the potential of bypassing any libc cache that FILE * may be using. I don't
> know whether we care about that, but if we do then this (and the previous)
> patch needs to be completely rethinked.
> If you read right from the fd, it will do the wrong thing as the cache may
> have read many bytes at once and reading from the fd will skip bytes.
> > Note that the current state is not very consistent either File::Read()
> uses fread() if we have a FILE*, but the offset version of File::Read
> always uses pread (via GetDescriptor(), as I do in this patch always), as
> there is no offset version of fread. I think this is a much bigger
> inconsistency than the one we have here.
> Agreed that there are bugs. We should see if anyone is using the "FILE *"
> part and remove it if possible. Some people might be using "FILE *" since
> it provides locking of the fd during reads and writes to stop multiple
> threads from borking each other, so if anyone is still using it, you can't
> just switch them away without looking very carefully at the code that is
> using the File object. Check and see if anyone is using the "FILE *"
> functionality and let me know what you find.
> https://reviews.llvm.org/D28305
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20170104/ec701e32/attachment.html>

More information about the lldb-commits mailing list