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 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> <5421FF2E DOT 4010709 AT sbcglobal DOT net> <20140924040432 DOT 22429 DOT qmail AT stuge DOT se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Precedence: bulk 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 > #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