X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=tCF21tF5vYzCBE/ZfFv9ndKti6Wed30jeREuX+4KPhg=; b=TFVM3pAhBi4oKRQVJM+fsRM9irEljcgxQYWtQasayi1Aao3VEqsd08lA7C/QThy/mf CX/KdWTlgRRR0L3fvORCjCM8EPfDTQs5DOcQt+xjYgIhkydSoABWbRMM8Y1LNBuoulDj Kuwtu+hcphcC3MmWqWJSApQqNtdMKRQDBJVlpOQn2lKZG0IoUMSRCDxfrUuQkDkNIADM RU+c7B4c8gBiZgAswYkNOwsOkqzQOAFdB2XhEIHyYc0xdfdJafSAQlHIzazw96uRx7di 5z4fPQeRvL1/iXjzIHOIo3dkYJ++2seEHl78UUxGaUqQ1tkLLOSKnhqcrSs9GixojOpd ZQhw== MIME-Version: 1.0 X-Received: by 10.42.205.132 with SMTP id fq4mr14119457icb.33.1433573125349; Fri, 05 Jun 2015 23:45:25 -0700 (PDT) In-Reply-To: <55727FED.7060509@iki.fi> 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> <834mmmp7f0 DOT fsf AT gnu DOT org> <83zj4enfns DOT fsf AT gnu DOT org> <55727FED DOT 7060509 AT iki DOT fi> Date: Sat, 6 Jun 2015 09:45:25 +0300 Message-ID: Subject: Re: __STRICT_ANSI__ and errno.h definitions [WAS: Re: DJGPP v2.05: some thoughts] From: "Ozkan Sezer (sezeroz AT gmail DOT com)" To: djgpp AT delorie DOT com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id t566jUHG008897 Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On 6/6/15, Andris Pavenis (andris DOT pavenis AT iki DOT fi) wrote: > On 06/05/2015 10:01 PM, Eli Zaretskii (eliz AT gnu DOT org) wrote: >>> From: Nick Bowler >>> Date: Fri, 5 Jun 2015 18:10:01 +0000 (UTC) >>> >>> On Fri, 05 Jun 2015 17:16:19 +0300, Eli Zaretskii (eliz AT gnu DOT org) wrote: >>>>> From: Martin Str|mberg >>>>> Date: Fri, 5 Jun 2015 12:29:43 +0000 (UTC) >>>>> >>>>> But, IIRC, C99 (or even perhaps C89) reserved any symbol starting with >>>>> E. >>>> Where do you see such language in C99? I don't see it, and neither do >>>> I see it in C11. But maybe I'm missing something, it's not like I've >>>> read the entire document top to bottom. >>> Names starting with E followed by a digit or an uppercase letter are >>> reserved if is included. >> I don't see this text in the standard. >> >>> C99ยง7.5p4 Errors : >>> >>> Additional macro definitions, beginning with E and a digit or E and >>> an uppercase letter, may also be specified by the implementation. >>> >>> This text was copied unchanged into C11. I am quite sure it was also >>> present in C89. >> It's indeed present in C89, but I don't see how it reserves these >> names. >> >> >> > It says that implementation may specify additional macro definitions > according to these restrictions > (begins with E and followed by either digit or capital letter) and that > should not be considered as > standard > violation. From other side also not adding additional definitions is OK > according to standard as > far as I > understand. So current DJGPP implementation does not violate standard. > > We are however free add these macros even when __STRICT_ANSI__ is defined. > > Tried for MINGW ( Konsole outpu gcc version 5.1.0 20150422 (Fedora MinGW > 5.1.0-1.fc22) (GCC)): > > Konsole output > [andris AT ap usr]$ echo "#include " | i686-w64-mingw32-gcc -x c > -std=c89 - -E -dD | egrep > --color=never '^#define\ E' > #define EPERM 1 > #define ENOENT 2 > #define ENOFILE ENOENT > #define ESRCH 3 > #define EINTR 4 > #define EIO 5 > #define ENXIO 6 > #define E2BIG 7 > #define ENOEXEC 8 > #define EBADF 9 > #define ECHILD 10 > #define EAGAIN 11 > ...... > > One is also getting the same behavior for Linux ( Konsole outpugggg gcc > version 5.1.1 20150422 (Red > Hat 5.1.1-1) (GCC)) > ): > > Konsole output > [andris AT ap usr]$ echo "#include " | gcc -x c -std=c89 - -E -dD | > egrep --color=never > '^#define\ E' > #define EPERM 1 > #define ENOENT 2 > #define ESRCH 3 > #define EINTR 4 > #define EIO 5 > #define ENXIO 6 > #define E2BIG 7 > #define ENOEXEC 8 > #define EBADF 9 > #define ECHILD 10 > #define EAGAIN 11 > ....... > > For DJGPP we're getting: > Konsole output > [andris AT ap usr]$ echo "#include " | i586-pc-msdosdjgpp-gcc -x c > -std=c89 - -E -dD | egrep > --color=never '^#define\ E' > #define EDOM 1 > #define ERANGE 2 > > [andris AT ap usr]$ echo "#include " | i586-pc-msdosdjgpp-gcc -x c > -std=c11 - -E -dD | egrep > --color=never '^#define\ E' > #define EDOM 1 > #define ERANGE 2 > #define EILSEQ 41 > > Konsole output > [andris AT ap usr]$ echo "#include " | i586-pc-msdosdjgpp-gcc -x c > -std=c1x - -E -dD | egrep > --color=never '^#define\ E' > #define EDOM 1 > #define ERANGE 2 > #define EILSEQ 41 > > As the result I would vote for removal of excluding additional macros when > __STRICT_ANSI__ is defined. > > Andris Yes please -- O.S.