bug-autoconf
[Top][All Lists]
Advanced

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

Re: alloca redeclaration warning on MinGW


From: Hrvoje Niksic
Subject: Re: alloca redeclaration warning on MinGW
Date: Sat, 02 Jul 2005 17:37:31 +0200
User-agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.17 (Jumbo Shrimp, linux)

Paul Eggert <address@hidden> writes:

> More likely it's the other way around.
> <http://msdn2.microsoft.com/library/wb1s57t5(en-us,vs.80).aspx>
> indicates that Visual Studio 2005 doesn't define alloca.  And
> <http://sourceforge.net/mailarchive/forum.php?forum_id=5120&max_rows=25&style=nested&viewmonth=200403>
> suggests that a #define for alloca was removed from mingw last year.

All right.  It is entirely possible that my testers are be using old
versions of the compilers.  I myself only have regular access to the
gratis Borland C compiler, which defines both alloca and _alloca in
malloc.h.

>>> Also, what is the difference between _MSC_VER, __BORLANDC__, and
>>> __MINGW32__?  Are these different compilers?
>>
>> They are different compilers.  What they have in common is that
>> they (these days) run in the Win32 environment,
>
> Is there a single symbol that all three define?

There might well be, but I don't know of one, especially one that
would be present before processing any system includes.  In Wget's
case I simplified things by having Windows Makefiles specify -DWINDOWS
-- but that is entirely Wget-specific.  (This is not defined for
Cygwin, which does a good enough job of emulating Unix.)

> For example, <http://megapov.inetart.net/manual-1.2/binaries.html>
> talks about __BORLANDC__, __DJGPP__, __MINGW32__, __CYGWIN__,
> __DMC__, and __WATCOMC__.  I doubt whether even this list is
> exhaustive.  Nor do I know which of these compilers require
> <malloc.h>.
>
> This sounds like a job for an Autoconf test rather than for trying
> to guess from predefined macros.

Note that the original code tested at least for _MSC_VER, so whichever
approach you choose, I don't see a particular reason to single it out.
Maybe a better approach would be to completely remove the
_MSC_VER/Windows case, and have programs that support Windows #include
<malloc.h> and do the necessary define in their own "system.h" (or
equivalent) files.

An Autoconf test would not be very useful on Windows (except for
Cygwin, which I don't even count as Windows) since it doesn't support
running configure.  However, it is quite possible to simply include a
working "config.h-windows" with the distribution.

To summarize, an alternative could be something like:

#if HAVE_ALLOCA_H
# include <alloca.h>
#elif defined WINDOWS
# include <malloc.h>
# ifndef alloca
#  define alloca _alloca
# endif
#elif defined __GNUC__
# define alloca __builtin_alloca
#elif defined _AIX
# define alloca __alloca
#else
# include <stddef.h>
# ifdef  __cplusplus
extern "C"
# endif
void *alloca (size_t);
#endif

The program's build process would have to make sure to #define
WINDOWS, either in a manually written config.h or using -DWINDOWS in
Windows-specific Makefiles.




reply via email to

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