[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: enum instead of #define for tokens
From: |
Akim Demaille |
Subject: |
Re: RFC: enum instead of #define for tokens |
Date: |
03 Apr 2002 15:56:47 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) |
>>>>> "Paul" == Paul Eggert <address@hidden> writes:
>> From: Akim Demaille <address@hidden> Date: 02 Apr 2002 16:34:35
>> +0200
>>
>> Does POSIX mandate something?
Paul> POSIX 1003.1-2001 requires that the header file must contain
Paul> #define directives for each token code assigned by yacc. The
Paul> symbols must be defined to be "numbers".
OK, thanks!
Paul> This raises another issue, though. Some pedantic compilers
Paul> complain about mixing enum and int. So if you make the above
Paul> change, the pedantic compilers will make you want to go through
Paul> bison.simple and manually replace 'int' with 'enum yytokentype'
Paul> where that is needed.
I was thinking about yyttype, for consistency with yystype, and
yyltype.
Paul> But that's not a good idea, as it would introduce compatibility
Paul> problems, since the enum type is not type-compatible with int,
Paul> so programs that contain declarations like `int yylex ();' will
Paul> break.
Indeed.
Paul> So, all in all I would do something like the following instead.
Paul> This is a more conservative change, and is less likely to break
Paul> things.
#ifndef YYTOKENTYPE
# if defined (__STDC__) || defined (__cplusplus)
/* Put the tokens into the symbol table, so that GDB and other debuggers
know about them. */
enum yytokentype {
FOO = 256,
BAR,
...
};
/* POSIX requires `int' for tokens in interfaces. */
# define YYTOKENTYPE int
# endif
#endif
#define FOO 256
#define BAR 257
...
It does look good, but would some people really use it? Now that I
know we are bound by POSIX to #define, I'm tempted to leave it as is
for C, and provide something better only for C++. What is your opinion?
Paul> The __cplusplus is for backward compatibility with folks who
Paul> compile C programs using C++ compilers; there seem to be a good
Paul> number of these people so I wouldn't shut them off right away
Paul> even if we have a different and better way to do it now.
Yep. Actually, I think I was wrong when I said that the trick you
implemented for 1.3x was not to be installed in 1.5x. It should
probably be applied there too.
- RFC: enum instead of #define for tokens, Akim Demaille, 2002/04/02
- Re: RFC: enum instead of #define for tokens, Miles Bader, 2002/04/02
- RE: enum instead of #define for tokens, Wayne Green, 2002/04/02
- Re: RFC: enum instead of #define for tokens, Paul Eggert, 2002/04/02
- Re: RFC: enum instead of #define for tokens,
Akim Demaille <=
- Re: RFC: enum instead of #define for tokens, Paul Eggert, 2002/04/03
- Re: RFC: enum instead of #define for tokens, Akim Demaille, 2002/04/03
- Re: RFC: enum instead of #define for tokens, Hans Aberg, 2002/04/03
- Re: RFC: enum instead of #define for tokens, Akim Demaille, 2002/04/04
- Re: RFC: enum instead of #define for tokens, Hans Aberg, 2002/04/04
- Re: RFC: enum instead of #define for tokens, Akim Demaille, 2002/04/04
- Re: RFC: enum instead of #define for tokens, Hans Aberg, 2002/04/04
- Re: RFC: enum instead of #define for tokens, Anthony DeRobertis, 2002/04/04
- Re: RFC: enum instead of #define for tokens, Akim Demaille, 2002/04/05
- Re: RFC: enum instead of #define for tokens, Anthony DeRobertis, 2002/04/05