[cfe-dev] clang-format sets executable permission on windows (openNativeFile ignores mode on Windows)

[Chris Tetreault via cfe-dev]

Hi,

                I'm having an issue where clang-format is setting the executable bit on all source files it modifies when using the -i parameter. I spent some time troubleshooting this issue today, and I found that clang-format create a new temporary file, writes the formatted source into that file, then copies it over the old file. Deep in the bowels of openNativeFile in lib/Support/Windows/Path.inc, in openNativeFileInternal, CreateFileW is called with a SECURITY_ATTRIBUTES with lpSecurityDescriptor = nullptr. The result of this is you get a new file with the default permissions based on whatever NTFS decides to do. On my machine, this ends up being a file with 755 mode. This is happening because the mode parameter to openNativeFile is unused. This issue occurs in clang-format 9, and on HEAD of master.

                I spent some time thinking about how to improve this state of affairs. I feel like just letting files modified by clang-format get their permissions changed severely limits the convenience of the tool. Just some thoughts I had:


  1.  Would it be so terrible if files created by openNativeFile on windows queried the default SECURITY_ATTRIBUTES and stripped executable permissions? Does anything actually need llvm to produce files with executable permissions? I did a quick search but can't find anywhere in the codebase that actually sets a value for mode.
  2.  How would we even map unix-style permissions to windows? I see in the MS docs that there are coarse-grained permission types that map to unix permissions (FILE_GENERIC_READ, FILE_GENERIC_WRITE, and FILE_GENERIC_EXECUTE). For file creation, the current user could be the owner. Perhaps all groups the user is a member of could get the group permissions, and maybe Authenticated Users for other?
  3.  On my previous project, we used clang-format, and I never had this issue. I was using a very old version though, so I don't know if my configuration is just different, or if this behavior changed at some point

Thanks,
                Christopher Tetreault
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200417/31a2d4c1/attachment.html>