X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Envelope-From:	paubert AT iram DOT es
Date:	Wed, 24 Sep 2014 08:21:44 +0200
From:	Gabriel Paubert <paubert AT iram DOT es>
To:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] Banging my head against the guile-for-windows wall
Message-ID:	<20140924062143.GA21949@visitor2.iram.es>
References:	<20140923045453 DOT 56dc3de2 AT akka>
	<CAOuGh8_bfL2KJDLt-qkU7v0wS3UBkbHeej6ScVLJJfHnOR_6oQ AT mail DOT gmail DOT com>
	<lvssr7$lun$1 AT ger DOT gmane DOT org>
	<5421FF2E DOT 4010709 AT sbcglobal DOT net>
	<lvtcdd$53a$1 AT ger DOT gmane DOT org>
	<20140924040432 DOT 22429 DOT qmail AT stuge DOT se>
MIME-Version:	1.0
In-Reply-To:	<20140924040432.22429.qmail@stuge.se>
User-Agent:	Mutt/1.5.21 (2010-09-15)
X-Spamina-Bogosity:	Unsure
X-Spamina-Spam-Score:	-0.2 (/)
X-Spamina-Spam-Report:	Content analysis details: (-0.2 points)
	pts rule name description
	---- ---------------------- --------------------------------------------------
	-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
	0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
	[score: 0.5001]
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, Sep 24, 2014 at 06:04:32AM +0200, Peter Stuge wrote:
> Kai-Martin Knaak wrote:
> > read.c: In function 'try_read_ci_chars':
> > read.c:983:3: warning: implicit declaration of function 'alloca' [-Wimplicit-function-declaration]
> >    char *chars_read = alloca (num_chars_wanted);
> >    ^
> > read.c:983:22: warning: incompatible implicit declaration of built-in function 'alloca'
> >    char *chars_read = alloca (num_chars_wanted);
> >                       ^
> 
> This is ugly but if void * and int are the same size it is harmless.
> 
> MSDN says the correct header file is malloc.h and that the function
> is called _alloca() as opposed to alloca(). Try including the header
> and adding a conditional define, into all source files with that
> warning.
> 
> #include <malloc.h>
> #ifndef alloca
> #define alloca _alloca
> #endif
> 
> 
> > posix.c: In function 'scm_execl':
> > posix.c:1144:3: warning: passing argument 2 of 'execv' from incompatible pointer type
> >    execv (exec_file, exec_argv);
> >    ^
> > In file included from /usr/local/src/mxe/usr/i686-pc-mingw32.static/include/unistd.h:13:0,
> >                  from ../lib/unistd.h:40,
> >                  from posix.c:50:
> > /usr/local/src/mxe/usr/i686-pc-mingw32.static/include/process.h:118:42: note: expected 'const char * const*' but argument is of type 'char **'
> >  _CRTIMP intptr_t __cdecl __MINGW_NOTHROW execv (const char*, const char* const*);
> >                                           ^
> 
> These are harmless, it's a mismatch between const and non-const. When
> the function takes const and a non-const is passed, there's no problem.
> 

I consider this one a spurious warning, it may probably be silenced by inserting
an useless and ugly cast, but I really wonder on which drugs the compiler
writers were when they decided to add it. You should always be able to pass
a non-const argument to a const parameter.

> 
> > From my scarce coding experiences long long ago "incompatible pointer
> > type" and "incompatible implicit declarations" ring a serious bell.
> 

Indeed. For the first one there are unavoidable occurences in low level code
but it can fixed by a proper cast (especially if the message is caused
by the distinction between char, signed char and unsigned char, one of 
the problems of C and derived languages).

> In principle correct, but when the only difference is const vs
> non-const it's not so bad.

Huh? I consider this message extremely stupid. Passing a const to 
a non-const is an error, the other way around should be silently 
accepted.
	
	Gabriel

- Raw text -