Date: Mon, 11 Oct 1999 16:17:53 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: pavenis AT lanet DOT lv cc: djgpp-workers AT delorie DOT com Subject: Re: xmalloc and xfree In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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? > 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.