On 5/28/20 8:46 PM, David Malcolm via Gcc-patches wrote:
> On Thu, 2020-05-28 at 16:51 -0300, Nicolas Bértolo wrote:
>>> I'm going to have to trust your Windows expertise here; the tempdir
>>> code looks convoluted to me, but perhaps that's the only way to do
>> it.
>>> (Microsoft's docs for "SECURITY_ATTRIBUTES" suggest to me that if
>>> lpSecurityDescriptor is NULL, then the directory gets a default
>>> security descriptor, and that this may mean it's only readable by
>> the
>>> user represented by the access token of the process [1], which
>> might
>>> suggest a simplification - but I'm very hazy on how the security
>> model
>>> in Windows works)
>>
>> I tested this and it gives write access to the "Authenticated Users"
>> group. 
> 
> Aha - sounds like that would be a problem.  Thanks for clarifying.
> 
>> The
>> way I did it gives access only to the user that owns the libgccjit
>> process. I
>> have to admit that it is a lot of code and it is hard to understand
>> unless you
>> know the security model of Windows well. I don't know it well, I
>> wrote this
>> keeping the documentation close and experimenting.
> 
> Thanks.
> 
>>> I was able to successfully bootstrap and regression test with your
>>> patch on x86_64-pc-linux-gnu.  I also verified that the result of
>> "make
>>> install" was not affected for my configuration.
>>
>> Great.
>>
>>> I've pushed your patch to master as
>>> c83027f32d9cca84959c7d6a1e519a0129731501.
>>>
>>> Thanks again for the patch
>>> Dave
>>
>> Thanks to you for all the good feedback.
>>
>> Nico.
> 

Hello,

A bit of a late review, some minor points:

1. Using .so on Windows for DLLs is fine.
2. The DLL name on Windows should use LIBGCCJIT_SONAME rather than
LIBGCCJIT_LINKER_NAME, so applications would load libgccjit.so.0 instead
of libgccjit.so directly. The linker command output needs to be
LIBGCCJIT_SONAME.
3. Ideally I would prefer to .cc too, though I see other C++ files also
written as .c.

Resend in case reply to list did not work,