[llvm] r185832 - Create files with the correct permission instead of changing it afterwards.

Sean Silva silvas at purdue.edu
Sat Jul 13 15:35:12 PDT 2013


On Fri, Jul 12, 2013 at 9:30 PM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

> On 12 July 2013 22:16, Sean Silva <silvas at purdue.edu> wrote:
> > The raw calls to open/close in this code (and the corresponding #ifdef's)
> > make me sad. It seems like the whole reason that this code is using raw
> > calls to open() and close() is because of
> >
> > 1. This call to sys::fs::setLastModificationAndAccessTime, which needs
> the
> > FD. Would it be possible to add a getter to raw_fd_ostream for getting
> the
> > FD? Then you could use tool_output_file.os().get_fd() instead of keeping
> the
> > FD around explicitly.
> >
> > 2. Setting the mode. It seems like we could just add an extra argument
> > (defaulted to 0644) to raw_fd_ostream's constructor, which can then just
> > pass it in on the call
> > <http://llvm.org/docs/doxygen/html/raw__ostream_8cpp_source.html#l00464
> >.
> >
> > Also can we use tool_output_file here (after adding a default parameter
> to
> > the constructor that gets passed though to raw_fd_ostream's constructor)?
> >
> > Also, for the O_* constants above, you can use the corresponding F_*
> flags
> > which will then get appropriately translated into O_* flags if necessary
> by
> > <http://llvm.org/docs/doxygen/html/raw__ostream_8cpp_source.html#l00451>
>
> My idea was to abstract the calls to open. Something like a
> sys::fs::openFile which would take llvm flags and translate them to
> open flags (similar to what the raw_fd_ostream constructor does). The
> problem with the getter is that I need raw_fd_ostream to not close the
> fd, which is a bit odd when it was the one that called open. What do
> you think?
>

I'm not sure I understand. The code calls close(FD) at the end of the
function, so presumably the raw_fd_ostream could just be moved out of the
block it is currently in?

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130713/28458357/attachment.html>


More information about the llvm-commits mailing list