Bruno Haible <[EMAIL PROTECTED]> writes:
> Ben Pfaff asked:
>> I have not yet signed papers for gnulib contributions. Should I?
>
> Yes, please. Not only for tmpfile, but also for your future contributions.
OK. I filled out and emailed request-assign.future to
[EMAIL PROTECTED] just now.
--
"T
Ben Pfaff asked:
> I have not yet signed papers for gnulib contributions. Should I?
Yes, please. Not only for tmpfile, but also for your future contributions.
Bruno
Bruno Haible <[EMAIL PROTECTED]> writes:
> Paul Eggert wrote:
>> I think gnulib is for porting GNU applications, and if GNU
>> applications assume glibc behavior for a function then it's OK to
>> replace a vendor's function that behaves differrently.
>
> OK. So I'm adding Ben's module, with the fo
Paul Eggert wrote:
> I think gnulib is for porting GNU applications, and if GNU
> applications assume glibc behavior for a function then it's OK to
> replace a vendor's function that behaves differrently.
OK. So I'm adding Ben's module, with the following modifications:
* tmpfile.c:
- Don't
Bruno Haible <[EMAIL PROTECTED]> writes:
> Paul, what's your opinion on this? Should gnulib includes overrides under
> the same function name, even if they contradict the respective platform's
> documentation?
I think gnulib is for porting GNU applications, and if GNU
applications assume glibc be
Ben Pfaff wrote:
> I agree that the Windows implementation is, arguably, C99 and
> POSIX compliant. But I claim that it has an unreasonably poor
> quality of implementation, bad enough that we should replace it.
> If a Unix-like system implemented its tmpfile in a similar way,
> by always attempti
Ben Pfaff wrote:
> There seems to be some kind of problem with
> FILE_FLAG_DELETE_ON_CLOSE, with which _O_TEMPORARY is presumably
> implemented, under Windows 95:
> http://cygwin.com/ml/cygwin-cvs/2003-q4/msg00025.html
>
> In fact, it appears that FILE_FLAG_DELETE_ON_CLOSE works on NT
> de
Bruno Haible <[EMAIL PROTECTED]> writes:
> 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
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
Bruno Haible <[EMAIL PROTECTED]> writes:
> So, to test whether native Woe32 API is available, use
>
> defined _WIN32 || defined __WIN32__
Ben Pfaff <[EMAIL PROTECTED]> writes:
> + [[#ifdef __WIN32__
> +
Under Windows, the tmpfile function is defined to always create
its temporary file in the root directory. Most users don't have
permission to do that, so it will often fail. I'm proposing a
"tmpfile" module that detects this situation and replaces tmpfile
with a better implementation.
The implem
11 matches
Mail list logo
