Undefined behavior & Co.

[valexey_u]

У столь широко разрекламированного UB есть еще братья, сестры и кузины. Они все разные и их следует различать.

Кроме undefined behavior еще бывает unspecified behavior, implementation-defined behavior, locale-specific behavior.

И хотя эта терминология взята из стандарта С++, сами эти замечательные друзья существуют практически во всех языках, в том же Обероне например (но там они явно не прописаны, так что приходится догадываться).

Чем они все отличаются друг от друга можно прочесть (кратко и на русском) вот тут: http://alenacpp.blogspot.ru/2005/08/unspecified-behavior-undefined.html

[DddIzer]

ну не... по идее UB должно отлавливаться как ошибка(алгоритм не может быть интерпретирован языком), в отличии от realization depended...
а в каком месте в описании Оберона (или КП) есть UB?  вроде как то я их не видел?

[valexey_u]

ну не... по идее UB должно отлавливаться как ошибка(алгоритм не может быть интерпретирован языком), в отличии от realization depended...
а в каком месте в описании Оберона (или КП) есть UB?  вроде как то я их не видел?

Ни в одном из описаний, насколько я помню, четко UB не прописано (видимо на символах экономили, чтобы в 16 страниц влезло), но они там очевидно есть. Ну, например там умалчивается что будет если поделить на ноль. Это явное UB. Ну и что будет после разименовывания нулевого указателя.

[DddIzer]

ну не... по идее UB должно отлавливаться как ошибка(алгоритм не может быть интерпретирован языком), в отличии от realization depended...
а в каком месте в описании Оберона (или КП) есть UB?  вроде как то я их не видел?

Ни в одном из описаний, насколько я помню, четко UB не прописано (видимо на символах экономили, чтобы в 16 страниц влезло), но они там очевидно есть. Ну, например там умалчивается что будет если поделить на ноль. Это явное UB. Ну и что будет после разименовывания нулевого указателя.

с чего бы это.. я так понимаю , что если что то не прописано, значит это  realization depended....
правда есть поганенький вопрос в сторону оберонов- а много ли приходится доопределять  реализацией в Оберонах,  и как это может повлиять на портабельность программ..

[valexey_u]

ну не... по идее UB должно отлавливаться как ошибка(алгоритм не может быть интерпретирован языком), в отличии от realization depended...
а в каком месте в описании Оберона (или КП) есть UB?  вроде как то я их не видел?

Ни в одном из описаний, насколько я помню, четко UB не прописано (видимо на символах экономили, чтобы в 16 страниц влезло), но они там очевидно есть. Ну, например там умалчивается что будет если поделить на ноль. Это явное UB. Ну и что будет после разименовывания нулевого указателя.

с чего бы это.. я так понимаю , что если что то не прописано, значит это  realization depended....
правда есть поганенький вопрос в сторону оберонов- а много ли приходится доопределять  реализацией в Оберонах,  и как это может повлиять на портабельность программ..

Это не является implementation-defined behavior просто потому, что implementation-defined behavior подразумевает что оно случается когда программа валидная, то есть будет точно хорошо, причем всегда одним и тем же способом, а как именно будет - см. доку на реализацию.

В случае деления на ноль - хорошо не будет :-) Да и в случае попытки пролезть по нулевому указателю тоже хорошо не будет.

Причем в случаях unspecified behavior, implementation-defined behavior это все должно быть явно указано в доке на язык а не реализацию.

Так что, если оставаться в терминах всех этих 4х behavior'ов, то остается только UB.

[DddIzer]

Это не является implementation-defined behavior просто потому, что implementation-defined behavior подразумевает что оно случается когда программа валидная,

а вот это с чего?

[valexey_u]

Это не является implementation-defined behavior просто потому, что implementation-defined behavior подразумевает что оно случается когда программа валидная,

а вот это с чего?

С этого:

Код: [Выделить]

  --implementation-defined behavior: Behavior, for a well-formed program
    construct  and  correct data, that depends on the implementation and
    that each implementation shall document.
http://www.csci.csusb.edu/dick/c++std/cd2/intro.html#intro.defs

[DddIzer]

Это не является implementation-defined behavior просто потому, что implementation-defined behavior подразумевает что оно случается когда программа валидная,

а вот это с чего?

С этого:

Код: [Выделить]

  --implementation-defined behavior: Behavior, for a well-formed program
    construct  and  correct data, that depends on the implementation and
    that each implementation shall document.
http://www.csci.csusb.edu/dick/c++std/cd2/intro.html#intro.defs

так это же определение из стана "врагов" .. там они дофига чего могут определить... вопрос в том, стоит ли их определениями пользоваться при трактовке Оберонного кода...

[valexey_u]

http://www.csci.csusb.edu/dick/c++std/cd2/intro.html#intro.defs

так это же определение из стана "врагов" .. там они дофига чего могут определить... вопрос в том, стоит ли их определениями пользоваться при трактовке Оберонного кода...

Ну, я же сказал, что "если оставаться в терминах всех этих 4х behavior'ов, то остается только UB.", если же начать фантазировать и придумывать свои определения этой четверки, то конечно можно будет подогнать под что угодно :-)

Но мне эта четвёрка представляется вполне разумной, не вижу смысла как-то это изменять плодя сущности.

[DddIzer]

Но мне эта четвёрка представляется вполне разумной, не вижу смысла как-то это изменять плодя сущности.

так я  иду дальше.. уменьшаю четверку.. до одной сущности, ибо не вижу с точки зрения языка (Оберона) плодить их... но может быть это  необходимо с точки зрения реализации?

[valexey_u]

Но мне эта четвёрка представляется вполне разумной, не вижу смысла как-то это изменять плодя сущности.

так я  иду дальше.. уменьшаю четверку.. до одной сущности, ибо не вижу с точки зрения языка (Оберона) плодить их... но может быть это  необходимо с точки зрения реализации?

Ну, конечно же есть. И для использования тоже - например тот же порядок вычислений аргументов функции - это типичный UsB а не UB :-)

Можно конечно заняться и сгенерить списочек всех этих B для оберона. Правда добавится пятый вариант под именем "ХЗ", ибо местами вообще там не ясно какое должно быть поведение (с точки зрения конструкций языка, типов, областей видимости).

То есть проблема оберона в том, что там UB распространяется не только на приложение которое собрано каким-то конкретным компилятором, но и на сам компилятор. Одну и ту же программу не противоречащую сообщению о языке, один компилятор в полном соответствии с описанием языка может собрать, а другой не собрать. И все тут будут правы.

[DddIzer]

Но мне эта четвёрка представляется вполне разумной, не вижу смысла как-то это изменять плодя сущности.

так я  иду дальше.. уменьшаю четверку.. до одной сущности, ибо не вижу с точки зрения языка (Оберона) плодить их... но может быть это  необходимо с точки зрения реализации?

Ну, конечно же есть. И для использования тоже - например тот же порядок вычислений аргументов функции - это типичный UsB а не UB :-)

Можно конечно заняться и сгенерить списочек всех этих B для оберона. Правда добавится пятый вариант под именем "ХЗ", ибо местами вообще там не ясно какое должно быть поведение (с точки зрения конструкций языка, типов, областей видимости).

То есть проблема оберона в том, что там UB распространяется не только на приложение которое собрано каким-то конкретным компилятором, но и на сам компилятор. Одну и ту же программу не противоречащую сообщению о языке, один компилятор в полном соответствии с описанием языка может собрать, а другой не собрать. И все тут будут правы.

вы не поняли Алексей, я ЗА Implementation defined, но против UB(ибо последний отношу к некачественной архитектуре языка)

[valexey_u]

вы не поняли Алексей, я ЗА Implementation defined, но против UB(ибо последний отношу к некачественной архитектуре языка)

UB это всегда плата за эффективность. Грубо говоря, оно нужно чтобы не пришлось вокруг нашего языка каждый раз строить виртуальную машину в которой было бы все так одинаково везде да предсказуемо.

Ну, то есть возможно где-то и существует язык который и портабельный и эффективный и имеет множество реализаций и высокоуровневый и при этом без UB, но я такого не встречал пока (среди тех, что копал достаточно глубоко).

[DddIzer]

например, разименование  NIL - указателя.. не имеет смысла с точки зрения обьектов порождаемых языком.. - а поскольку явно в описание ничего про это не говорится,
 то возможной обработкой этой ситуации (с точки зрения реализации) может быть  рантайм проверка (аналогичная проверки границы индексов массива).

[valexey_u]

например, разименование  NIL - указателя.. не имеет смысла с точки зрения обьектов порождаемых языком.. - а поскольку явно в описание ничего про это не говорится,
 то возможной обработкой этой ситуации (с точки зрения реализации) может быть  рантайм проверка (аналогичная проверки границы индексов массива).

Кстати, да, выход за границу индексов массива это еще один UB в Обероне :-)