X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient:	djgpp AT delorie DOT com
Message-ID:	<5572D93B.3030505@iki.fi>
Date:	Sat, 06 Jun 2015 14:27:55 +0300
From:	"Andris Pavenis (andris DOT pavenis AT iki DOT fi)" <djgpp AT delorie DOT com>
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version:	1.0
To:	djgpp AT delorie DOT com
Subject:	Re: __STRICT_ANSI__ and errno.h definitions [WAS: Re: DJGPP v2.05:
	some thoughts]
References:	<55673F0B DOT 1090103 AT iki DOT fi> <83twuwwshg DOT fsf AT gnu DOT org> <55675040 DOT 9030008 AT iki DOT fi> <556F6E49 DOT 8010006 AT gmx DOT de> <556FCCDF DOT 7080005 AT iki DOT fi> <83bngvr0ef DOT fsf AT gnu DOT org> <557078B1 DOT 9040004 AT iki DOT fi> <201506041613 DOT t54GDT8m014488 AT delorie DOT com> <5570B1F7 DOT 1070509 AT iki DOT fi> <83pp5aprqw DOT fsf AT gnu DOT org> <mks4nl$1o8$1 AT speranza DOT aioe DOT org> <834mmmp7f0 DOT fsf AT gnu DOT org> <mksolp$uta$1 AT dont-email DOT me> <83zj4enfns DOT fsf AT gnu DOT org> <55727FED DOT 7060509 AT iki DOT fi> <83d219nwlo DOT fsf AT gnu DOT org>
In-Reply-To:	<83d219nwlo.fsf@gnu.org>
Reply-To:	djgpp AT delorie DOT com

On 06/06/2015 10:07 AM, Eli Zaretskii (eliz AT gnu DOT org) wrote:
>> Date: Sat, 06 Jun 2015 08:06:53 +0300
>> From: "Andris Pavenis (andris DOT pavenis AT iki DOT fi)" <djgpp AT delorie DOT com>
>>
>> As the result I would vote for removal of excluding additional macros when __STRICT_ANSI__ is defined.
> What about -pedantic -- do we still want it to flag any symbols that
> are not in the standard?
>
>
They do not get flagged dor Linux or Mingw (as far as I checked with Linux to Mingw 
cross-compiler). Do we really need to be more pedantic? (especially with our limited resources)

Change which I committed to trunk fixes current problems with C++ by defining macros when use of 
corresponding C++ standard is being requested. We have been living with absence of these macros for 
C when __STRICT_ANSI__ is defined for many years.

So I could commit same change also for v2.05 and build a release (lets name it release candidate 
for now as actual release would require rearranging files between djgpp/beta, djgpp/current and 
djgpp/deleted)

After that:
1) we could leave things as they are
2) if we can recognize that standard permits defining these constants when __STRICT_ANSI__ is 
defined then we could remove excluding #define statements

I would prefer variant 2 as it
a) would make maintenance easier for little resources we have
b) it would make life easier for users (I mean users who are developing own software using DJGPP).
c) it would make our implementation slightly nearer to ones of Linux and Mingw as currently only 
DJGPP hides these macros when __STRICT_ANSI__ is defined

Andris

- Raw text -