From:	pavenis AT lanet DOT lv
Message-ID:	<B0000104742@stargate.astr.lu.lv>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com
Date:	Mon, 11 Oct 1999 19:02:18 +0300
MIME-Version:	1.0
Subject:	Re: xmalloc and xfree
References:	<B0000104719 AT stargate DOT astr DOT lu DOT lv>
In-reply-to:	<Pine.SUN.3.91.991011161301.29606A-100000@is>
X-mailer:	Pegasus Mail for Win32 (v3.12a)
Reply-To:	djgpp-workers AT delorie DOT com

On 11 Oct 99, at 16:17, Eli Zaretskii wrote:

> 
> On Mon, 11 Oct 1999 pavenis AT lanet DOT lv wrote:
> 
> > > Perhaps we should uncomment the prototype of xmalloc and friends in 
> > > stdlib.h, but only #ifdef __cplusplus.
> > > 
> > > Comments?
> > 
> > Should we have them there at all. 
> 
> That's the case now: the prototypes are commented-out, so they are 
> effectively ``not there''.  The user who had this problem compiled a 
> program that called xmalloc and got compilation errors.  I was asking 
> maybe we should enable the prototypes for C++ only.  If we do, at least 
> people who use xmalloc will have their C++ programs compiled.  With the 
> current setup, they cannot compile them at all.
> 
> > > Btw, isn't that -ansi-pedantic default of C++ a good reason to complain 
> > > about to the GCC maintainers?  As far as I understand, that means, in 
> > > particular, that C++ programs will not see prototypes of non-ANSI 
> > > functions in our C headers, right?  I guess there are other calamities 
> > > as well.
> > 
> > Not true. Corresponding defines are not added when preprocessing
> > C++ sources. So preprocessor knows nothing about this C++ compiler
> > feature.
> 
> Do I understand correctly that -ansi does not define __STRICT_ANSI__ in 
> the C++ compiler?

If You specify -ansi then -D__STRICT_ANSI__ is added to command 
line of cpp

If You specify -fpedantic or -fpedantic-errors it's not added. The 
defaulting to -fpedantic-errors in C++ compiler is hidden rather deep
(gcc/cp/decl.c if I remeber correctly) and it doesn't even appear in 
assembler output with -fverbose-asm. 
> 
> > Also one always can use command line option -fpermissive to push 
> > through source which violates C++ standard.
> 
> I don't think this is a good solution.  A ``normal'' compilation should 
> not require any non-default switches, unless we think *every* 
> compilation should use it.

No special switches required for programs that doesn't violate C++ 
standard. So if one want to use 
	void main(void)
(or similar illegal constructions) in C++ then he/shy will have to use -
fpermissive (-fpedantic will also work as we'll get warnings also them). 

One example:
	void foo (void * ptr) { delete ptr; } 
is now illegal (we'll get error without -fpermissive). This was discussed 
in gcc mailing lists and it was said that correct is to write
       void foo (void * ptr) { operator delete (ptr); }
Perhaps this is one topic for FAQ. (such construction were used for 
example in earlier versions of rhtvision)

Andris

- Raw text -