删除“if（a = b）”"警告 [英] Removing "if (a = b)" warning
问题描述
有没有一种标准的方法可以从语句中删除C编译器可能产生的警告：
if（a = b）{}
我不想这样做：
if（（a = b）！= 0）{}
因为我的a = b实际上包含在一个宏中，该宏可能被用作
作为语句或表达式（例如）if
语句。
如果它有任何区别，这就是我正在努力做的事情。在
中为了解决特定C编译器的限制，它将不允许p ++（或任何其他指针算法）在
$ b上正常工作$ b 64KB边界，我想出了一些宏，其中一个是：
#define FARPTR_INC（p）p =（void far *）（（（ULONG）（ p））+ sizeof（*（p）））
现在我能做到：
UBYTE远* pb;
UWORD far * pw;
ULONG far * pl;
FARPTR_INC（pb）; //替换为：pb ++; （地址加1）
FARPTR_INC（pw）; //替换为：pw ++; （地址加2）
FARPTR_INC（pl）; //替换：pl ++; （地址加4）
我也可以这样做：
func（FARPTR_INC（p））; //替换为：func（p ++）;
但如果我这样做：
if（FARPTR_INC（p））{}
然后我收到警告，因为编译器有理由接受视图
我可能错过了等号并意外地转了一个
平等比较分配。
[请原谅我的C代码中的C ++注释风格。我知道你们都是clc中的纯粹主义者，这是正确的，但我选择在我的C代码中使用C ++注释因为我使用的每个C编译器（或者现在可能会使用）
处理它;-)
....哦，像UBYTE这样的东西是#define UBYTE unsigned char。等等]
Is there a standard way to remove the warning that a C compiler might
produce from the statement:
if (a = b) {}
I don''t want to do:
if ((a = b) != 0) {}
Because my "a = b" is actually contained in a macro that might be used
as a statement or as an expression within (for example) an "if"
statement.
If it makes any difference, here''s exactly what I''m trying to do. In
order to get around a limitation of a particular C compiler that will
not allow p++ (or any other pointer arithmetic) to work correctly across
64KB boundaries, I have come up with a few macros, one of which is:
#define FARPTR_INC(p) p=(void far *)(((ULONG)(p))+sizeof(*(p)))
Now I can do:
UBYTE far *pb;
UWORD far *pw;
ULONG far *pl;
FARPTR_INC(pb); // Replacement for: pb++; (adds 1 to address)
FARPTR_INC(pw); // Replacement for: pw++; (adds 2 to address)
FARPTR_INC(pl); // Replacement for: pl++; (adds 4 to address)
I can also do:
func(FARPTR_INC(p)); // Replacement for: func(p++);
But if I do:
if (FARPTR_INC(p)) {}
Then I get a warning since the compiler is justifiably taking the view
that I might have missed an equals sign and accidentally turned an
equality comparison into an assignment.
[Please excuse the C++ commenting style in my C code. I know you''re all
C purists in c.l.c, and rightly so, but I choose to use C++ comments in
my C code because every C compiler I use (or probably ever will use now)
handles it ;-)
.... oh, and stuff like UBYTE is "#define UBYTE unsigned char" etc.]
推荐答案
2005-10-26，Stephen< sp ******* @ yahoo.co .UK>写道：
On 2005-10-26, Stephen <sp*******@yahoo.co.uk> wrote:
有没有一种标准方法可以从语句中删除C编译器可能产生的警告：
if（a = b ）{}
我不想这样做：
if（（a = b）！= 0）{}
因为我的a = b实际上包含在一个宏中，该宏可以用作语句或表达式（例如）if
语句中的表达式。
如果它来自一个宏，宏应该有自己的括号，以避免
优先级问题，比如说...
如果它有任何区别，这就是我正在努力做的事情。为了解决特定C编译器的限制，它不允许p ++（或任何其他指针算术）在64KB边界上正常工作，我想出了一些宏，其中之一是：
#define FARPTR_INC（p）p =（void far *）（（（ULONG）（p））+ sizeof（*（p）））
#define FARPTR_INC（p）（（p）=（void far *）（（（ULONG）（p））+ sizeof（*（p））））
这符合避免错误的传统方式，如果（（a = b）），则需要做b $ b。
现在我可以这样做：
UBYTE远* pb;
UWORD far * pw;
ULONG far * pl;
FARPTR_INC（pb）; //替换为：pb ++; （地址加1）
FARPTR_INC（pw）; //替换为：pw ++; （地址加2）
FARPTR_INC（pl）; //替换：pl ++; （地址加4）
我也可以这样做：
func（FARPTR_INC（p））; //替换为：func（p ++）;
不，不是。它取代了func（++ p） - 对于p ++你需要以下宏
：
#define FARPTR_POSTINC（p）（（p ）=（void far *）（（ULONG）（p）+ sizeof \
*（p））），（void far *）（（ULONG）（p）-sizeof *（p ）））
但如果我这样做：
if（FARPTR_INC（p））{}
然后我收到警告，因为编译器是有理由认为我可能错过了一个等号并意外地将
平等比较转换为一项任务。
[请原谅我的C代码中的C ++注释风格。我知道你们都是clc中的C纯粹主义者，这是正确的，但我选择在我的C代码中使用C ++注释，因为我使用的每个C编译器（或者现在可能会使用）
处理它;-)
然而没有指针算术？
...哦，像UBYTE这样的东西是#define UBYTE unsigned炭"等等。]
Is there a standard way to remove the warning that a C compiler might
produce from the statement:
if (a = b) {}
I don''t want to do:
if ((a = b) != 0) {}
Because my "a = b" is actually contained in a macro that might be used
as a statement or as an expression within (for example) an "if"
statement.
If it''s from a macro the macro should have its own parentheses to avoid
precedence problems anyway, say...
If it makes any difference, here''s exactly what I''m trying to do. In
order to get around a limitation of a particular C compiler that will
not allow p++ (or any other pointer arithmetic) to work correctly across
64KB boundaries, I have come up with a few macros, one of which is:
#define FARPTR_INC(p) p=(void far *)(((ULONG)(p))+sizeof(*(p)))
#define FARPTR_INC(p) ((p)=(void far *)(((ULONG)(p))+sizeof(*(p))))
This fits with the traditional way of avoiding the error, which is
to do if((a = b)).
Now I can do:
UBYTE far *pb;
UWORD far *pw;
ULONG far *pl;
FARPTR_INC(pb); // Replacement for: pb++; (adds 1 to address)
FARPTR_INC(pw); // Replacement for: pw++; (adds 2 to address)
FARPTR_INC(pl); // Replacement for: pl++; (adds 4 to address)
I can also do:
func(FARPTR_INC(p)); // Replacement for: func(p++);
no it''s not. it replaces func(++p) - you''d need the following macro
for p++:
#define FARPTR_POSTINC(p) (((p)=(void far*)((ULONG)(p)+sizeof \
*(p))), (void far *)((ULONG)(p)-sizeof *(p)))
But if I do:
if (FARPTR_INC(p)) {}
Then I get a warning since the compiler is justifiably taking the view
that I might have missed an equals sign and accidentally turned an
equality comparison into an assignment.
[Please excuse the C++ commenting style in my C code. I know you''re all
C purists in c.l.c, and rightly so, but I choose to use C++ comments in
my C code because every C compiler I use (or probably ever will use now)
handles it ;-)
And yet no pointer arithmetic?
... oh, and stuff like UBYTE is "#define UBYTE unsigned char" etc.]
编译器也没有处理typedef，我接受了吗？
Compiler doesn''t handle typedefs either, i take it?
2005- 10-26，Jordan Abel< jm **** @ purdue.edu>写道：
On 2005-10-26, Jordan Abel <jm****@purdue.edu> wrote:
[东西，看其他消息]
[stuff, see other message]
PS顺便说一下，是什么让你认为你可以安全地做到这一点？ 远指针
可能没有整数表示，其中添加它将导致
下一个相邻的存储单元格。
顺便说一下，试试
#define PTR_ADD（a，i）（&（a）[i]）
#define PTR_SUB（a ，i）PTR_ADD（a，-i）
#define PTR_EQP（a，i）（（p）= PTR_ADD（a，i））
#define PTR_EQM（ a，i）（（p）= PTR_SUB（a，i））
#define PTR_PPX（p）PTR_EQP（a，1）
#define PTR_MMX（p） PTR_EQM（a，1）
#define PTR_XPP（p）（PTR_PPX（p），PTR_SUB（p，1））
#define PTR_XMM（p）（PTR_MMX（ p），PTR_ADD（p，1））
更简洁，不需要铸造，并保持类型安全。
顺便说一句，如果我是你，我会抛弃蹩脚的编译器。
PS Incidentally, what makes you think you can safely do this? A "far pointer"
may not have an integer representation of which adding to it will result in the
next adjacent memory cell.
incidentally, try
#define PTR_ADD(a,i) (&(a)[i])
#define PTR_SUB(a,i) PTR_ADD(a,-i)
#define PTR_EQP(a,i) ((p)=PTR_ADD(a,i))
#define PTR_EQM(a,i) ((p)=PTR_SUB(a,i))
#define PTR_PPX(p) PTR_EQP(a,1)
#define PTR_MMX(p) PTR_EQM(a,1)
#define PTR_XPP(p) (PTR_PPX(p),PTR_SUB(p,1))
#define PTR_XMM(p) (PTR_MMX(p),PTR_ADD(p,1))
More concise, don''t require casting, and retain type-safety.
Incidentally, i''d ditch the crappy compiler if i were you.
2005-10-26，Jordan Abel< jm **** @ purdue.edu> ;写道：
On 2005-10-26, Jordan Abel <jm****@purdue.edu> wrote:
2005-10-26，Jordan Abel< jm **** @ purdue.edu>写道：
On 2005-10-26, Jordan Abel <jm****@purdue.edu> wrote:
[东西，见其他消息]
[stuff, see other message]
[更多东西]
[more stuff]
顺便提一句，我说 ;顺便"方式太多了。
在没有注意到的情况下发布了两次之前我读了两遍
Incidentally, I say "incidentally" way too much. I read over that twice before
posting it without noticing, too
这篇关于删除“if（a = b）”"警告的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
