破坏编译器头的宏 [英] Macros that break compiler headers

查看:68
本文介绍了破坏编译器头的宏的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

您好,


我最近遇到的代码定义了一个特殊的宏:


#define local static


gcc没有问题,但另一个(实验性)编译器我是b / b
评估输出错误列表。


显然,标识符本地用于

编译器标题中的几个地方。当标识符更改为

a保留关键字时,地狱会松散。


编译器实施者是否应该更加谨慎选择

标识符,或者宏观定义是否违法?


-

问候,抱怨

解决方案

2004年12月16日星期四11:08:53 +0100,Grumble写道:

你好,

我最近遇到过代码定义了一个特殊的宏:

#define local static
gcc没有问题,但另一个(实验性)编译器我评估输出冗长错误列表。

显然,标识符''local''在
编译器的头文件中的几个地方使用。当标识符更改为保留关键字时,地狱会松散。

编译器实现者是否应该更加谨慎地选择
标识符,或者宏定义是否非法?




我看起来很好。我找不到

可以匹配本地的任何保留标识符集。所以实现不应该使用它。


劳伦斯


在文章< pa **** ************************@netactive.co.uk> ,

Lawrence Kirby< lk **** @ netactive.co.uk>写道:

....

显然,标识符本地用于其中的几个地方
编译器的标题。当标识符更改为保留关键字时,地狱会松散。

编译器实现者是否应该更加谨慎地选择
标识符,或者宏定义是否非法?



对我来说很好看。我找不到任何可以与本地匹配的保留标识符集。所以实现不应该使用它。




但这确实在C中留下了这个差距 - 我觉得很烦人 - 这是

你不可能真正确定什么是保留,什么不是 - 其他

比通过不断跟上标准文件和/或发布(和
$ b) $ b在这里发火焰。


OP在杯子里张贴了类似物品关于定义(或

typedef''d - 不确定哪个)单词stat的代码这导致了问题

(基本上,因为实验编译器自动包含了

stat.h)。在我看来,语言应该为分离程序员和实现者命名空间的更好的条款做好准备。我想这对于C来说太晚了。


如果所有用户符号都以大写字母开头,它会起作用吗?


Grumble< de ***** @ kma.eu.org>写道:

我最近遇到的代码定义了一个特殊的宏:

#define local static

gcc没问题它,但另一个(实验性)编译器我评估输出一个冗长的错误列表。

显然,标识符本地用于其中的几个地方
编译器的标题。当标识符更改为保留关键字时,地狱会松散。

编译器实现者是否应该更加谨慎地选择
标识符,或者宏定义是否非法?




这是实施的错。它可能会有类似的问题,或类似的问题,如


int * local;


或者


void local(char * txt,int len);


放在它的标题之前。所有这些,包括你的#define,都是完全合法的;实施是保持其爪子关闭标识符

,这些标识符不是为其使用而保留的,当地是一个。


Richard


Hello,

I recently came across code that defined a peculiar macro:

#define local static

gcc had no problem with it, but another (experimental) compiler I am
evaluating output a lengthy list of errors.

Apparently, the identifier ''local'' is used in several places within that
compiler''s headers. Hell breaks loose when the identifier is changed to
a reserved keyword.

Should the compiler implementers be more careful in their choice of
identifiers, or is the macro definition somehow illegal?

--
Regards, Grumble

解决方案

On Thu, 16 Dec 2004 11:08:53 +0100, Grumble wrote:

Hello,

I recently came across code that defined a peculiar macro:

#define local static

gcc had no problem with it, but another (experimental) compiler I am
evaluating output a lengthy list of errors.

Apparently, the identifier ''local'' is used in several places within that
compiler''s headers. Hell breaks loose when the identifier is changed to
a reserved keyword.

Should the compiler implementers be more careful in their choice of
identifiers, or is the macro definition somehow illegal?



It looks fine to me. I couldn''t find any sets of reserved identifiers that
can match local. So the implementation should not be using it.

Lawrence


In article <pa****************************@netactive.co.uk> ,
Lawrence Kirby <lk****@netactive.co.uk> wrote:
....

Apparently, the identifier ''local'' is used in several places within that
compiler''s headers. Hell breaks loose when the identifier is changed to
a reserved keyword.

Should the compiler implementers be more careful in their choice of
identifiers, or is the macro definition somehow illegal?



It looks fine to me. I couldn''t find any sets of reserved identifiers that
can match local. So the implementation should not be using it.



But that does leave open this gap - which I find annoying - in C. Which is
that you can''t ever really be sure what is reserved and what isn''t - other
than by constantly keeping up with standards documents and/or posting (and
getting flamed) here.

The OP posted a similar item in c.u.p. about code that defined (or
typedef''d - not sure which) the word "stat" and this caused problems
(basically, because the "experimental compiler" automatically included
stat.h). It seems to me that languages ought to make better provisions for
separating the programmers and implementors namespaces. I suppose it is
too late for C.

Would it work if all user symbols started with a capital letter?


Grumble <de*****@kma.eu.org> wrote:

I recently came across code that defined a peculiar macro:

#define local static

gcc had no problem with it, but another (experimental) compiler I am
evaluating output a lengthy list of errors.

Apparently, the identifier ''local'' is used in several places within that
compiler''s headers. Hell breaks loose when the identifier is changed to
a reserved keyword.

Should the compiler implementers be more careful in their choice of
identifiers, or is the macro definition somehow illegal?



It''s the implementation''s fault. It would probably have the same, or
similar, problems with declarations like

int *local;

or

void local(char *txt, int len);

placed before its headers. All of those, including your #define, are
perfectly legal; the implementation is to keep its paws off identifiers
which are not reserved for its use, of which local is one.

Richard


这篇关于破坏编译器头的宏的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆