什么时候发出诊断 [英] When to emit diagnistics
问题描述
最近我们讨论了以下代码：
void f（long * lp）{* lp = 0; }
int main（void）{int i; F（&安培;ⅰ）;回归我; }
lcc-win在正常模式下没有发出任何诊断信息，并且没有
发出具有更高警告级别的诊断。
仅在最高警告级别发出诊断：
lcc -A -A foo.c
将通过警告进行诊断。
为什么？
因为在Windows（32位和64位）下有
绝对没有
long和int之间的实际差异。它们是完全等同的类型。
诊断只会将CLUTTER和NOISE添加到编译器输出的
。
问题是，如果编译器发出太多诊断信息，那么重要的诊断信息将被忽视，被不重要的噪声吞噬掉。
。
请注意，即使具有最高警告级别，Microsoft C也不会诊断此
。
这就是原因决定背后。有些人喜欢
heathfield或者becarisse使用这个作为证明lcc-win是
无用等等。他们通常的东西。请注意，lcc-win不仅仅是为了讨好comp.lang.c中的学生，但是它很有用
来做真正的工作。我的目标不是取悦这里的b $ b学生。
-
jacob navia
jacob at jacob point remcomp point fr
logiciels / informatique
http://www.cs.virginia.edu/~lcc-win32
jacob navia写道：
< blockquote class =post_quotes>
最近我们讨论了以下代码：
void f（long * lp）{* lp = 0; }
int main（void）{int i; F（&安培;ⅰ）;回归我; }
lcc-win在正常模式下没有发出任何诊断信息，并且没有
发出具有更高警告级别的诊断。
仅在最高警告级别发出诊断：
lcc -A -A foo.c
将通过警告进行诊断。
好。一个问题解决了。现在记录手册中的切换。
为什么？
因为在Windows（32位和64位）下有
绝对没有
long和int之间的实际差异。它们是完全等同的类型。
诊断只会将CLUTTER和NOISE添加到编译器输出的
。
问题是，如果编译器发出太多诊断信息，那么重要的诊断信息将被忽视，被不重要的噪声吞噬掉。
确实是所有有效点。
请注意，例如Microsoft C不会诊断此
即使具有最高警告级别。
我自己没有测试过这个，但就我所知的其他人（即RH）来说，它确实是这样的。称_in符合模式_。所以请不要继续比较苹果和桃子。
这就是决定背后的原因。有些人喜欢
heathfield或者becarisse使用这个作为证明lcc-win是
无用等等。他们通常的东西。请注意，lcc-win不仅仅是为了讨好comp.lang.c中的学生，但是它很有用
来做真正的工作。目的不是为了取悦这里的b $ b。
没有人声称win-lcc没用。这里唯一的声明（以及充足的证明
）是win-lcc不符合（与你的说法不同）
C89 / C90或C99。
所以它是一个类似C语言的编译器，不多也不少。那不是
让它变得毫无用处。
再见，Jojo
jacob navia写道：
最近我们讨论了以下代码：
void f（long * lp）{* lp = 0; }
int main（void）{int i; F（&安培;ⅰ）;回归我; }
lcc-win在正常模式下没有发出任何诊断信息，并且没有
发出具有更高警告级别的诊断。
仅在最高警告级别发出诊断：
lcc -A -A foo.c
问题是你没有（据我所知）*记录*这个
开关组合。未记载的功能是IMO比未实现的功能更糟糕。
将通过警告进行诊断。
为什么？
因为在Windows（32位和64位）下有
绝对没有实际的区别
长和一个int。它们完全等同于类型。
你在这里假设在Windows下使用lcc-win
编译的任何标准C程序以后都没有机会被移植到另一个
系统。
对于认为
便携性很重要的用户来说，此警告绝对必不可少。
< blockquote class =post_quotes>
诊断只会将CLUTTER和NOISE添加到编译器输出的
。
那么为什么不添加一个特定的开关来启用这个类的警告，
喜欢说gcc？或者您可以安排''-A''开关取一个
数值，这将指定警告级别。需要
*'-A''开关的两个*实例非常违反直觉。
不要害怕添加更多命令线路开关。 AC编译器是一个很好的工具，一个专业的程序员应该将它作为工作的一部分彻底研究它。
问题是，如果编译器发出太多诊断信息，那么重要的诊断信息将被忽视，被不重要的噪声吞噬掉。
这就是不同的诊断水平。如果程序员
明确要求*所有*可能的诊断，那么他可能会准备好处理一些无害的诊断。
请注意，即使具有最高警告级别，Microsoft C也不会诊断此
。
这就是背后的原因决策。有些人喜欢
heathfield或者becarisse使用这个作为证明lcc-win是
无用等等。他们通常的东西。请注意，lcc-win不仅仅是为了讨好comp.lang.c中的学生，但是它很有用
来做真正的工作。目的不是为了取悦这里的b $ b。
没有人说lcc-win是无用的或仅仅是为了讨好的学生。这个
线程的开发是因为你声称lcc-win符合C90
和C99，显然并非如此。
无论一致性如何，HLL的一个真正优势是可以进行严格的自动检查。人们很容易出现错误和错别字。捕获它们的工具（即使冒着一些
误报的风险）也优于那个在这个b
方面能力降低的工具。
IME英特尔的编译器具有比甚至gcc更好的诊断功能。你b $ b会很好地研究它的行为并努力模仿它。 IMO的
课程。
jacob navia说：
最近我们讨论了以下代码：
void f（long * lp）{* lp = 0; }
int main（void）{int i; F（&安培;ⅰ）;回归我; }
lcc-win在正常模式下没有发出任何诊断信息，并且没有
发出具有更高警告级别的诊断。
仅在最高警告级别发出诊断：
lcc -A -A foo.c
将通过警告进行诊断。
违反约束和语法
错误需要诊断消息。如果你的实现没有问题，它就不符合
语言规范。
为什么？
因为在Windows（32位和64位）下，
绝对没有
long和int之间的实际差异。它们是完全等同的类型。
诊断只会将CLUTTER和NOISE添加到编译器输出的
。
问题是，如果编译器发出太多诊断信息，那么重要的诊断信息将被忽视，被不重要的噪声吞噬掉。
语法错误和约束违规非常重要。
>
请注意，即使具有最高警告级别，Microsoft C也不会诊断此
。
骗子。当你第一次声称这个时，可以合理地假设你被误认为是b $ b。但在你声明它三次之后，我检查了它并告诉你
MSVC在符合模式下调用时正确地诊断出这个错误，并且
你回复了并且lcc-win还，在一篇文章中加上12分钟左右的时间
在你的何时发出诊断信息之前文章。所以你知道并接受了微软C确实诊断出这个错误的b $ b，这让你成为一个骗子
假装它没有。
这是决定背后的原因。有些人喜欢
heathfield或者becarisse使用这个作为证明lcc-win是
无用等等。
骗子。我从未声称lcc-win是无用的。我*声称
它不是C编译器，你似乎同意，因为你似乎没有看到
要求C90或C99一致性对于它。
他们通常的东西。请注意，lcc-win不仅仅是为了讨好comp.lang.c中的学生，但是它很有用
来做真正的工作。目的不是为了取悦这里的b $ b。
如果你想完成真正的工作，请使用一个编译器来实现它声称要实现的
语言。
< br $>
-
Richard Heathfield< http://www.cpax.org.uk>
电子邮件：-http：// www。 + rjh @
谷歌用户：< http://www.cpax.org.uk/prg/writings/googly.php>
Usenet是一个奇怪的放置" - dmr 1999年7月29日
Recently we had a discussion about the following code:
void f(long *lp) { *lp = 0; }
int main(void) { int i; f(&i); return i; }
lcc-win doesn''t emit any diagnostic in normal mode, and doesn''t
emit a diagnostic with the higher warning level.
It emits a diagnostic only in the highest warning level:
lcc -A -A foo.c
will diagnostic that with a warning.
Why?
Because under windows (32 and 64 bits) there is
absolutely no PRACTICAL difference between a
long and an int. They are completely equivalent types.
The diagnostic would just add CLUTTER and NOISE to
the output of the compiler.
The problem is that if the compiler emits too many diagnostics
the important ones will go unnoticed, swallowed by the noise
of the unimportant ones.
Note that Microsoft C, for instance will not diagnose this
even with the highest warning level.
This are the reasons behind the decision. Some people like
heathfield or becarisse use this as a "proof that lcc-win is
useless", etc. Their usual stuff. Note that lcc-win is not
just for pleasing pedants in comp.lang.c but it is useful
for doing REAL work. The objective is not to please
pedants here.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote:Recently we had a discussion about the following code:
void f(long *lp) { *lp = 0; }
int main(void) { int i; f(&i); return i; }
lcc-win doesn''t emit any diagnostic in normal mode, and doesn''t
emit a diagnostic with the higher warning level.
It emits a diagnostic only in the highest warning level:
lcc -A -A foo.c
will diagnostic that with a warning.Good. One problem solved. Now document that switch in your manual.
Why?
Because under windows (32 and 64 bits) there is
absolutely no PRACTICAL difference between a
long and an int. They are completely equivalent types.
The diagnostic would just add CLUTTER and NOISE to
the output of the compiler.
The problem is that if the compiler emits too many diagnostics
the important ones will go unnoticed, swallowed by the noise
of the unimportant ones.All valid points, indeed.
Note that Microsoft C, for instance will not diagnose this
even with the highest warning level.Haven''t tested this myself, but a far as I understood others (namely RH), it
it does diagnose this if called _in conforming mode_. So please don''t
continue comparing apples with peaches.
This are the reasons behind the decision. Some people like
heathfield or becarisse use this as a "proof that lcc-win is
useless", etc. Their usual stuff. Note that lcc-win is not
just for pleasing pedants in comp.lang.c but it is useful
for doing REAL work. The objective is not to please
pedants here.Nobody claimed win-lcc to be useless. The only claim here (and plenty proof
for it) was that win-lcc does not (unlike your claim) conform to either
C89/C90 or C99.
So it is a compiler for a C-like language, no more, no less. That doesn''t
make it useless.
Bye, Jojo
jacob navia wrote:
Recently we had a discussion about the following code:
void f(long *lp) { *lp = 0; }
int main(void) { int i; f(&i); return i; }
lcc-win doesn''t emit any diagnostic in normal mode, and doesn''t
emit a diagnostic with the higher warning level.
It emits a diagnostic only in the highest warning level:
lcc -A -A foo.cThe problem is you have not (as far as I can tell) *documented* this
switch combination. Undocumented features are IMO worse than
unimplemented features.
will diagnostic that with a warning.
Why?
Because under windows (32 and 64 bits) there is
absolutely no PRACTICAL difference between a
long and an int. They are completely equivalent types.You are assuming here that any Standard C program compiled with lcc-win
under Windows has no chance of later being ported to a different
system.
This warning is absolutely essential for a user who considers
portability to be important.
The diagnostic would just add CLUTTER and NOISE to
the output of the compiler.Then why not add a specific switch for enabling warnings of this class,
like say gcc? Or you could arrange for the ''-A'' switch to take a
numeric value which would specify the warning level. Necessitating
*two* instances of the ''-A'' switch is very counter-intuitive.
Don''t be afraid to add more command line switches. A C compiler is a
serious tool, and a professional programmer is expected to study it
thoroughly as a part of his job.
The problem is that if the compiler emits too many diagnostics
the important ones will go unnoticed, swallowed by the noise
of the unimportant ones.That''s what different diagnostic levels are for. If a programmer
explicitly asks for *all* possible diagnostics, then he is presumably
prepared to deal with some innocuous ones.
Note that Microsoft C, for instance will not diagnose this
even with the highest warning level.
This are the reasons behind the decision. Some people like
heathfield or becarisse use this as a "proof that lcc-win is
useless", etc. Their usual stuff. Note that lcc-win is not
just for pleasing pedants in comp.lang.c but it is useful
for doing REAL work. The objective is not to please
pedants here.No one said lcc-win was "useless" or just for "pleasing pedants". This
thread developed because you claimed that lcc-win conforms to both C90
and C99 which is clearly not the case.
Regardless of conformance, one of the real advantages of HLLs is the
rigorous automated checking that is possible. People are prone to
errors and typos. A tool that catches them (even at the risk of some
false positives) is superior to one that has reduced ability in this
regard.
IME Intel''s compiler has somewhat better diagnostics than even gcc. You
would do well to study it''s behaviour and strive to emulate it. IMO of
course.
jacob navia said:
Recently we had a discussion about the following code:
void f(long *lp) { *lp = 0; }
int main(void) { int i; f(&i); return i; }
lcc-win doesn''t emit any diagnostic in normal mode, and doesn''t
emit a diagnostic with the higher warning level.
It emits a diagnostic only in the highest warning level:
lcc -A -A foo.c
will diagnostic that with a warning.A diagnostic message is required for constraint violations and syntax
errors. If your implementation doesn''t issue one, it doesn''t conform to
the language spec.
Why?
Because under windows (32 and 64 bits) there is
absolutely no PRACTICAL difference between a
long and an int. They are completely equivalent types.
The diagnostic would just add CLUTTER and NOISE to
the output of the compiler.
The problem is that if the compiler emits too many diagnostics
the important ones will go unnoticed, swallowed by the noise
of the unimportant ones.Syntax errors and constraint violations are pretty important.
>
Note that Microsoft C, for instance will not diagnose this
even with the highest warning level.Liar. When you first claimed this, it was reasonable to assume you were
mistaken. But after you claimed it three times, I checked it and told you
"MSVC diagnoses this error properly when invoked in conforming mode", and
you replied "and lcc-win also", in an article timestamped 12 minutes or so
before your "When to emit diagnistics" article. So you knew and accepted
that Microsoft C does indeed diagnose this error, which makes you a liar
for pretending that it doesn''t.
This are the reasons behind the decision. Some people like
heathfield or becarisse use this as a "proof that lcc-win is
useless", etc.Liar. I have never claimed that lcc-win is useless. I *have* claimed that
it isn''t a C compiler, and you seem to agree, since you don''t appear to
claim either C90 or C99 conformance for it.
Their usual stuff. Note that lcc-win is not
just for pleasing pedants in comp.lang.c but it is useful
for doing REAL work. The objective is not to please
pedants here.If you want to get real work done, use a compiler that implements the
language it claims to implement.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
这篇关于什么时候发出诊断的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
