Mail Archives: djgpp/2015/06/06/01:07:11
On 06/05/2015 10:01 PM, Eli Zaretskii (eliz AT gnu DOT org) wrote:
>> From: Nick Bowler <nbowler AT draconx DOT ca>
>> 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 <ams AT ludd DOT luth DOT se>
>>>> 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 <errno.h> is included.
> I don't see this text in the standard.
>
>> C99§7.5p4 Errors <errno.h>:
>>
>> 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 <errno.h>" | 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 <errno.h>" | 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 <errno.h>" | 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 <errno.h>" | 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 <errno.h>" | 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
PS: Renaming subject as thread is becoming too long
- Raw text -