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 < revi...@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 > > > >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
