未定义的行为似乎是错误的，是一个很大的错 [英] undefined behaviour seems wrong and a big error
问题描述
2005年2月7日星期一21:28:30 GMT，Keith Thompson< ks *** @ mib.org>
写道：
On Mon, 07 Feb 2005 21:28:30 GMT, Keith Thompson <ks***@mib.org>
wrote:
" Romeo Colacitti" < WW ***** @ gmail.com>写道：
"Romeo Colacitti" <ww*****@gmail.com> writes:
Chris Torek写道：
Chris Torek wrote:
文章< 42 *********** @ mindspring.com>
pete< pf*****@mindspring.com>写道：[...]>如果你有
> int array [1];
>然后
> array [-1]是一个左值的例子，它没有将
>指向一个对象。使用这样的左值将是不确定的行为。
再次，在C99中显然是正确的，但在C89中没有（技术上）。但这只是意味着C89标准有缺陷。
In article <42***********@mindspring.com>
pete <pf*****@mindspring.com> wrote:[...] >If you have
> int array[1];
>then
> array[-1] is an example of an lvalue which doesn''t refer
>to an object. The use of such an lvalue would be undefined behavior.
Again, apparently true in C99, but not (technically) in C89. But
this just means the C89 standard has a defect.
C99更糟糕，因为根据上述标准几乎每个表达都无法解决对于不完整的类型或函数类型是一个
LVALUE。所以像2 + 3这样的东西是C99中的左值。我只会在C99中修改那个错误的句子，它显然必须是一个错字（他们忘了提一个左值指定一个对象。）
C99 is worse, because as per the said standard almost every expression
that doesn''t resolve to an incomplete types or function type is an
LVALUE. So something like 2+3 is an lvalue in C99. I''ll just modify
that errant sentence in the C99, it must obviously be a typo (they
forgot to mention that an lvalue "designates an object.")
唉，这不是错字。在C90中，左值被定义为一个表达式（具有对象类型或除了void之外的不完整类型）
，其指定对象。给定
int * ptr;
表达式* ptr可能会或可能不会指定一个对象（例如，它不是ptr == NULL）。所以严格来说，你不能总是确定表达式是否是运行时的左值，这显然不是意图。
C99试图通过删除来纠正这个问题。绝对要求
左值必须指定一个物体;左值现在是具有对象类型或除void之外的不完整类型的表达式;
如果左值在评估时未指定对象，则
行为未定义。 "严格来说，42是左值（它是一个带有对象类型的表达式） - 并且评估它会调用未定义的行为。再次，这显然不是意图。
Alas, it wasn''t a typo. In C90, an lvalue is defined as "an
expression (with an object type or an incomplete type other than void)
that designates an object". The flaw in this definition, given
int *ptr;
the expression *ptr may or may not designate an object (it doesn''t of
ptr==NULL, for example). So strictly speaking, you can''t always
determine whether an expression is an lvalue until runtime, which
clearly was not the intent.
C99 attempted to correct this by dropping the absolute requirement
that an lvalue must designate an object; an lvalue is now "an
expression with an object type or an incomplete type other than void;
if an lvalue does not designate an object when it is evaluated, the
behavior is undefined." Strictly speaking, 42 is an lvalue (it''s an
expression with an object type) -- and evaluating it invokes undefined
behavior. Again, this clearly was not the intent.
我不知道编译器科学但是未定义的行为
是错了，我不明白为什么未定义的行为必须存在
行为必须只有
1）编译器不接受表达式：错误
或
2）编译器接受表达式并且每个符合标准的编译器
将其转换为相同的行为
结束
如果有人写* s = ++ * s;这是你的未定义的行为
编译器没有编译......
I don''t are aware of compiler science but "undefined behaviour"
is WRONG, I don''t see why "undefined behaviour" has to exist
The behaviour has to be only
1) Compiler do not accept the expression: error
or
2) Compiler accept the expression and every conforming compiler
translate that in the same "behaviour"
END
if someone write *s=++*s; and this is your "undefined behaviour"
compiler has not compile...
推荐答案
RoSsIaCrIiLoIA写道：
RoSsIaCrIiLoIA wrote:
我不知道编译科学
然后是什么让你觉得你有资格提出意见？
但是未定义的行为
是错误的，
是的，所以不要调用它。
我不喜欢我们明白为什么未定义的行为必须存在
这很明显。
行为必须只是
1）编译器不接受表达式：error
或
2）编译器接受表达式，并且每个符合标准的编译器都会在相同的行为中翻译它。
END
罚款。去编写一种观察到这种行为的语言。
C不是。
如果有人写* s = ++ * s;这是你的未定义的行为
编译器没有编译...
I don''t are aware of compiler science
Then what makes you feel you are qualified to offer an opinion on it?
but "undefined behaviour"
is WRONG,
Yup, so don''t invoke it.
I don''t see why "undefined behaviour" has to exist
That much is obvious.
The behaviour has to be only
1) Compiler do not accept the expression: error
or
2) Compiler accept the expression and every conforming compiler
translate that in the same "behaviour"
END
Fine. Go write a language in which that behaviour is observed.
C isn''t it.
if someone write *s=++*s; and this is your "undefined behaviour"
compiler has not compile...
随意编写自己的C编译器，在其中诊断
在任意C程序中每次出现未定义的行为。
Feel free to write your own C compiler, in which you diagnose
every occurrence of undefined behaviour in an arbitrary C program.
未定义的行为永远不会出错。它做什么总是正确的。
Undefined behavior is never wrong. What ever it does is always right.
在文章< v0 ****************** **************@4ax.com>，
RoSsIaCrIiLoIA< n@esiste.ee>写道：
....
In article <v0********************************@4ax.com>,
RoSsIaCrIiLoIA <n@esiste.ee> wrote:
....
我不知道编译科学，但未定义的行为
是错的，我不是看看为什么未定义的行为必须存在
行为必须只是
1）编译器不接受表达式：错误
或
2）编译器接受表达式和每个符合标准的编译器
将其翻译成相同的行为
如果有人写* s = ++ * s;这是你的未定义的行为
编译器没有编译...
I don''t are aware of compiler science but "undefined behaviour"
is WRONG, I don''t see why "undefined behaviour" has to exist
The behaviour has to be only
1) Compiler do not accept the expression: error
or
2) Compiler accept the expression and every conforming compiler
translate that in the same "behaviour"
END
if someone write *s=++*s; and this is your "undefined behaviour"
compiler has not compile...
这就是被称为C语言的哲学D
（ www.digitalmars.com） 。所说的那种语言的想法是，事物
应该是正确的还是错误的（不是无穷无尽的灰色阴影，而不是C的情况）和编译器是能够分辨是非。
显然，无论好坏，这都不是C的情况。我认为
如果有帮助的话那些进来并且抱怨C不是
Java或Perl（或任何其他安全带语言）的人，只要他们看到
" C"想（并在他们的脑海中看到）便携式装配工。这将有助于他们意识到C不可能被安全带束缚。
That''s the philosophy of the C-like language known as "D"
(www.digitalmars.com). The stated idea of that language is that things
should be either right or wrong (not the endless shades of grey that is
the situation in C) and that the compiler is able to tell right from wrong.
Obviously, for better or worse, this is not the situation with C. I think
it would help a lot if those folks who come in and complain that C isn''t
Java or Perl (or any other safety-belted language) would, whenever they see
"C" think (and see in their minds) "portable assembler". That would help
them realize how unlikely it is that C could be safety-belted.
这篇关于未定义的行为似乎是错误的，是一个很大的错的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
