[cfe-dev] Clang violates the mkstemp() contract?

Kees van Reeuwijk reeuwijk at few.vu.nl
Wed Jul 14 12:59:39 PDT 2010

On 14 Jul 2010, at 21:09, Török Edwin wrote:

> The file should probably not be removed at all. If there is concern
> that the file stays there after process exit, it should be added to
> removeFileOnSignal.

Well, clang is actually not interested in that particular file, because it wants to append a .o or .s after the filename that was generated. That makes the cleanup a bit trickier.

Also, clang uses mktemp() if mkstemp() is not available on a particular platform, and in that case clang should actively create the file as soon as it gets the name. 

>> Which seems to confirm that an unwarranted assumption is made.
>> The reason this works on many platforms is because there the unique
>> filename is generated by first attempting to use a name based on a
>> random number. If a file with that name exists, the name is then
>> modified to avoid existing names. However, on Minix the first attempt
>> uses the process id, so you'll always get the same temporary filename
>> if the previous ones do not exist (any more), on other platforms that
>> is far less likely (but not impossible).
> Sounds like mkstemp() on Minix is fairly predictable then.

That's correct, but if you're implying that that is a security concern: AFAIK mkstemp() is supposed to be an atomic operation and therefore predictability is not a concern.

Kees van Reeuwijk

More information about the cfe-dev mailing list