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
Hi,
This is the yearly FAQ posting about the symbols defined on C/C++ compilations
on Windows.
1) The compiler indicators:
- Mingw, Cygwin: __GNUC__
- MSVC: _MSC_VER
- Borland:__TURBOC__, __BORLANDC__
2) The CPU indicators for x86:
- Mingw, Cygwin: _X86_, __i386__
-
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__
> +
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 wrote:
> 3) Operating system:
> - Cygwin default: __CYGWIN32__
> - Cygwin when the installer wants to use native Woe32 API (option -mwin32):
> __CYGWIN32__, _WIN32
This should be __CYGWIN__ and not __CYGWIN32__. The former is the
canonical name, the latter is
Brian Dessent wrote:
> This should be __CYGWIN__ and not __CYGWIN32__.
Yes, you are right. My bad. Here is the corrected summary:
1) The compiler indicators:
- Mingw, Cygwin: __GNUC__
- MSVC: _MSC_VER
- Borland:__TURBOC__, __BORLANDC__
2) The CPU indicators for x86:
-
Eric Blake wrote:
> there is too much risk that a user
> will use those characters in his local encoding, but not the
> byte sequence that M4 recognizes based on a different
> encoding of those characters.
Indeed. I thought this problem could be solved by having every file declare
its quote charac
Eric Blake wrote:
> One more misfeature of changequote - changequote(,) is not
> portable. The BSD folks have been trying to get their m4
> implementation to copy enough of GNU m4's traits that it
> can be used in place of GNU M4 to support autoconf.
But we don't need to care about that. We aren'
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
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
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
Pre-C99 versions of snprintf often had an interface different
from the C99 interface: they would return -1 when the buffer was
too small, and the "size" argument was not necessarily
interpreted the same way. However, the current Gnulib snprintf
module doesn't check whether snprintf is C99-complian
It's a bit of a pain that this will reject all cross-compiled snprintfs.
Is there some way you can test for this at compile-time?
Does the nonstandard snprintf have exactly the same signature as the
C99 snprintf? If not, we should be able to catch this at
compile-time.
Does the nonstandard imple
Bruno Haible <[EMAIL PROTECTED]> writes:
> Brian Dessent wrote:
>> This should be __CYGWIN__ and not __CYGWIN32__.
>
> Yes, you are right. My bad. Here is the corrected summary:
This is very useful, and I have been referencing to your posts
describing this a few times. Would it be possible to pu
14 matches
Mail list logo
