bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fix inadequate Windows implementation of tmpfile


From: Bruno Haible
Subject: Re: fix inadequate Windows implementation of tmpfile
Date: Fri, 16 Feb 2007 01:46:10 +0100
User-agent: KMail/1.5.4

Hello Ben,

Thanks for proposing this tmpfile override, and for bringing _O_TEMPORARY
to our attention.

However, in gnulib we usually try to not override a function unless it's
clearly broken. (We didn't do that with 'malloc' and 'realloc' for some
time, and it caused hassles, because some modules were expecting a glibc
compatible malloc and some weren't... Likewise for strstr more recently.)

Here, it's debatable whether the tmpfile() function in MSVCRT is broken:
On one hand, ISO C 99 says
   "It should be possible to open at least TMP_MAX temporary files during
    the lifetime of the program..."
which isn't fulfilled, as you say, if the user doesn't have the permissions.
(Btw, such situations can also occur on Unix! KDE becomes unusable when
/tmp is full.)

On the other hand, Microsoft's doc of tmpfile
  http://msdn2.microsoft.com/en-us/library/x8x7sakw(VS.80).aspx
and of tmpfile_s
  http://msdn2.microsoft.com/en-us/library/b3dz6009(VS.80).aspx
explicitly says
  "The temporary file is created in the root directory."

So, your replacement doesn't fulfill the Microsoft doc. Therefore, I think
you should choose a different name for your function, since you want it
to behave differently than the documented behaviour of tmpfile() on Windows.

-------------

The _O_TEMPORARY flag is interesting. It appears to be portable to all
versions of Windows since Woe95. What can you say about its reliability?
The native tmpfile() uses this flag as well. Is a file created with tmpfile()
on Windows deleted when you interrupt the program with Ctrl-C / Ctrl-Break?

-------------

> +                                                  [[#ifdef __WIN32__

This #if doesn't take into account several Windows platforms. See the other
mail of today.

-------------

> I using the clean-temp module instead, as a
> more portable solution, but then I needed to interpose upon
> fclose (and perhaps close as well) to delete the temporary file
> when it was closed, which quickly turned into a mess.

Can you elaborate, please? clean-temp guarantees that the file will be
removed in most cases. You want it removed earlier, as soon as the fclose
happens? To save disk space?

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]