Здравствуйте, Ikemefula, Вы писали:
I>Эдак и про Виндовс можно сказать — ошибки не в Виндовсе а в прикладных программах. Каково ?
Ну ты обычно так и говоришь
Re[2]: Ломать ли совместимость в недокументированной области
Здравствуйте, Игoрь, Вы писали:
И>Здравствуйте, Michael7, Вы писали:
И>Ну здесь проблема скорее из серии маркетинг vs программинг. Без веских причин я бы ничего не менял. Какие были веские причины у разработчиков — хз. Не вижу проблем, почему нельзя было добавить новую функцию.
Здесь хорошо сказано почему: http://www.rsdn.ru/forum/philosophy/4036422.aspx
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, Игoрь, Вы писали:
И>>Здравствуйте, Michael7, Вы писали:
И>>Ну здесь проблема скорее из серии маркетинг vs программинг. Без веских причин я бы ничего не менял. Какие были веские причины у разработчиков — хз. Не вижу проблем, почему нельзя было добавить новую функцию. DOO>Здесь хорошо сказано почему: http://www.rsdn.ru/forum/philosophy/4036422.aspx
И что? У людей то проблемы появились только после явного изменения кода. Даже могу развернуть аргумент в обратную сторону: если многие компиляторы так оптимизируют эту функцию, то зачем вообще было менять? Я все же думаю, что компиляторы осторожнее оптимизируют даже стандартную библиотеку и работают с реализацией, а не с названием, какие-то реализации инлайнятся в пару инструкций, какие-то — нет. Вообще, не хочу переходить в сугубо техническую часть, потому что проблема здесь в другом: серьезные изменения были внесены через попу. Нужно было: а) провести анализ и понять как много продуктов валятся, принять взвешенное решение; б) объяснить свою мотивацию пользователям; в) о breaking changes следовало бы информировать заранее.
Re[10]: Ломать ли совместимость в недокументированной област
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, March_rabbit, Вы писали:
PD>>>Ты неправ. Если эта старая программа работала многие годы, то можно гарантировать, что писал ее не лопух. Программы, написанные на С лопухами, помирают в младенческом возрасте M_>>то есть, допустим, если изначально при написании программы UB был равен "ничего не случилось", а через 10 лет он вдруг превратился в "process terminated" то виноваты, естественно, разработчики компилятора?
PD>В огороде бузина, а в Киеве дядька. Я совсем о другом — о том, что, как правило, лопухи не в состоянии написать программу на С++, которая бы то и дело не падала, а посему ей 10 лет не прожить.
Re[8]: Ломать ли совместимость в недокументированной области
Здравствуйте, Vi2, Вы писали:
Vi2>Здравствуйте, March_rabbit, Вы писали:
M_>>то есть, чтобы научить людей правильно использовать либы и читать документацию надо выкинуть все проверки из системных функций или натыкать ассертов? Чтобы любой неправильный параметр приводил к смерти? Только так? Ведь, выходит, что если сделали обход потенциальной ошибки, то сами и виноваты, что народ плевал на документацию "не падает, значит, крутой код".
Vi2>Эта функция в libc не выдерживает свои инварианты и сломалась бы на первом юнит-тесте после изменения. Значит, разработчики libc поставляют её "как получилось" или не используют тестирование в своих поделках. Дело тут ведь не в нарушении пользователями документации (это само собой плохо), а в нарушении инвариантов опубликованных функций.
Думаю, скорее всего у них юнит-тесты проверяют документированный интерфейс. Не должна функция memcpy сохранять живым кусок памяти при копировании пересекающихся блоков — не будет на это юнит-теста. Такой юнит-тест будет у функции memmove. И нельзя оправдываться инвариантами, когда речь идет о наружении контракта фукнции (в котором сказано: работаю только с непересекаюшимися блоками памяти).
Re[10]: Ломать ли совместимость в недокументированной област
DOO>Я замечу, что memcpy на ассемблере — это (без учета инициализации регистров) одна инструкция. DOO>Так что накладные расходы на рантайм проверку совершенно неприемлемы.
Современные компиляторы одну не используют, и не всегда инлайнят. Там довольно сложная функция учитывающая кеш, упреждающую выборку и т. п.
Когда длина известна и небольшая обычно несколькими mov обходятся.
Даже эта "одна" инструкция с REP префиксом по сути цикл.
Re[4]: Ломать ли совместимость в недокументированной области
Здравствуйте, Игoрь, Вы писали:
И>И что? У людей то проблемы появились только после явного изменения кода. Даже могу развернуть аргумент в обратную сторону: если многие компиляторы так оптимизируют эту функцию, то зачем вообще было менять?
Это самый интересный вопрос. Потому что во многих языках подобные функции вообще не являются частью библиотек, а относятся к выражениям самого языка. Здесь сработала низкоуровневость C.
И>проблема здесь в другом: серьезные изменения были внесены через попу. Нужно было: а) провести анализ и понять как много продуктов валятся, принять взвешенное решение;
Я приводил сравнение с протоколами. Сколько сегодня существует реализаций того же TCP — никто никогда не скажет. Если завтра потребуется наконец-то использовать какое-то зарезервированное поле TCP заголовка, то что делать? Никакой хоть сколько-то адекватный анализ провести невозможно. Для glibc это корректное сравнение — она ведь черт знает где используется, никто даже всех дистрибутивов линукса перечислить не сможет.
И>б) объяснить свою мотивацию пользователям; в) о breaking changes следовало бы информировать заранее.
А может это и было сделано?
Вообще, конечно, стоило бы.
Re: Ломать ли совместимость в недокументированной области?
Здравствуйте, Michael7, Вы писали:
M>Предположим есть некий давно присутствующий на рынке программный продукт, с API, которое использует огромное число разработчиков.
M>Причем некоторые из разработчиков используют это API не описанным в документации способом или даже прямо там запрещенном (не в юридическом смысле) и никаких проблем от этого до сих пор не возникало, потому что, де-факто, оно работало нужным образом, хотя и не позволенным документацией.
M>В один прекрасный момент разработчики чего-то там у себя переписали и внезапно недокументированное поведение функции из API изменилось, что поломало совместимость и привело к ошибкам в работе и возмущениям.
M>И вот кто тут прав?
Для программистов лучше забить на совместимость, для менеджеров важнее customer satisfaction.
Собственно никто не прав или все правы.
Больше влияние менеджеров — больше внимания на такие штуки. Собственно ситуация MS vs Linux.
WBR, Igor Evgrafov
Re[7]: Ломать ли совместимость в недокументированной области
Здравствуйте, March_rabbit, Вы писали:
M_>Оно и в ассемблере выглядит почти так же (там будет что-то типа to[i] = from[i]; ++i ).
Нет, там будет одна инструкция ассемблера по копированию блока памяти.
M_>в то же время если это копирование с пересечением (memmove), то по-хорошему, надо еще и направление копирования выбирать, так, чтобы не затереть кусок источника перед тем, как до него дойдет очеред быть скопированным.
Да, а тут разветвление.
Re[2]: Ломать ли совместимость в недокументированной области
Здравствуйте, Шахтер, Вы писали:
Ш>Пусть ка этот идиот уберет своё дерьмо сам.
Абсолютно согласен. Только в случае с идиотами, разрабатывающими glibc 17 лет назад, во-первых, этих идиотов уже может и не быть, во-вторых, от их дерьма появилось уже много производного дерьма, которое они если и начнут убирать, то очень быстро в нём захлебнутся.
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Ломать ли совместимость в недокументированной области
Здравствуйте, March_rabbit, Вы писали:
M_>Думаю, скорее всего у них юнит-тесты проверяют документированный интерфейс. Не должна функция memcpy сохранять живым кусок памяти при копировании пересекающихся блоков — не будет на это юнит-теста. Такой юнит-тест будет у функции memmove. И нельзя оправдываться инвариантами, когда речь идет о наружении контракта фукнции (в котором сказано: работаю только с непересекаюшимися блоками памяти).
После отработки тестов на правильных и неправильных данных они просигнализируют, что изменения сделаны критические. К тому же, и у memcpy, и у memmove будут одинаковые тесты.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Шахтер, Вы писали:
Ш>>Пусть ка этот идиот уберет своё дерьмо сам.
IT>Абсолютно согласен. Только в случае с идиотами, разрабатывающими glibc 17 лет назад, во-первых, этих идиотов уже может и не быть, во-вторых, от их дерьма появилось уже много производного дерьма, которое они если и начнут убирать, то очень быстро в нём захлебнутся.
Здравствуйте, Шахтер, Вы писали:
IT>>Абсолютно согласен. Только в случае с идиотами, разрабатывающими glibc 17 лет назад, во-первых, этих идиотов уже может и не быть, во-вторых, от их дерьма появилось уже много производного дерьма, которое они если и начнут убирать, то очень быстро в нём захлебнутся.
Ш>Ты не понял смысла написанного.
Я то как раз понял. А ты видимо не совсем. Могу разжевать. Первое дерьмо появилось в 1993 году в функции, которая позволяла себя использовать не по назначению. Дальше это дерьмо всего лишь расползлось по другим приложениям. Я с тобой абсолютно согласен — каждый должен убирать за собой сам. Вот только боюсь, что с тем количеством кала, которое породило решение 1993-го года разработчикам glibc уже не справиться.
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Ломать ли совместимость в недокументированной области
Здравствуйте, IT, Вы писали:
IT>Я то как раз понял. А ты видимо не совсем. Могу разжевать. Первое дерьмо появилось в 1993 году в функции, которая позволяла себя использовать не по назначению.
Тут уж мильон раз говорили, что нельзя добавлять такую проверку в функцию, которая реализуется одной инструкцией процессора.
Re[5]: Ломать ли совместимость в недокументированной области
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Шахтер, Вы писали:
IT>>>Абсолютно согласен. Только в случае с идиотами, разрабатывающими glibc 17 лет назад, во-первых, этих идиотов уже может и не быть, во-вторых, от их дерьма появилось уже много производного дерьма, которое они если и начнут убирать, то очень быстро в нём захлебнутся.
Ш>>Ты не понял смысла написанного.
IT>Я то как раз понял. А ты видимо не совсем. Могу разжевать.
IT>Первое дерьмо появилось в 1993 году в функции, которая позволяла себя использовать не по назначению.
Нет здесь дерьма. Есть функция, поведение которой удовлетворяет требованиям стандарта. Как она работает за пределами своей области определения -- не важно.
Разработчик не обязан за этимм следить. Нечего по этому поводу разводить дискуссию.
IT>Дальше это дерьмо всего лишь расползлось по другим приложениям.
Разработчики библиотеки не несут ответственности за то, что программисты пишут код, нарушая правила языка.
Это первое. Второе, изменение библиотеки под нужды говнокодеров в данном случае, как я объяснил выше, не исправит ситуацию.
Что-то последнее время на RSDN е день тупка какой-то.
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, IT, Вы писали:
IT>>Я то как раз понял. А ты видимо не совсем. Могу разжевать. Первое дерьмо появилось в 1993 году в функции, которая позволяла себя использовать не по назначению. DOO>Тут уж мильон раз говорили, что нельзя добавлять такую проверку в функцию, которая реализуется одной инструкцией процессора.
Тут дело даже не в этом. Человек пишет код. У него есть требования на реализацию, кроме того, он должен написать данную функцию максимально эффективно.
Как при этом будет работать данная функция, если её неправильно используют, его волновать не должно совершенно. Как получится, поведение не определено в этом случае.
Здравствуйте, Шахтер, Вы писали:
IT>>Первое дерьмо появилось в 1993 году в функции, которая позволяла себя использовать не по назначению. Ш>Нет здесь дерьма. Есть функция, поведение которой удовлетворяет требованиям стандарта. Как она работает за пределами своей области определения -- не важно.
Очень даже важно. По исходным кодам библиотке C/C++ компиляторов лично я учился программировать.
Ш>Разработчик не обязан за этимм следить. Нечего по этому поводу разводить дискуссию.
Согласен. Ты, как разработчик не должен. Разработчики glibc обязаны.
IT>>Дальше это дерьмо всего лишь расползлось по другим приложениям. Ш>Разработчики библиотеки не несут ответственности за то, что программисты пишут код, нарушая правила языка.
Плох тот язык правила которого так легко нарушить.
Ш>Это первое. Второе, изменение библиотеки под нужды говнокодеров в данном случае, как я объяснил выше, не исправит ситуацию.
Говнокодеры в 1993 году написали код, который породил других говнокодеров. Говнокодеры в 2010-ом пытаются из овна слепить другое овно. Лепили бы пулю, было бы понятно. А так...
Ш>Что-то последнее время на RSDN е день тупка какой-то.
Смени сайт, может тупка пройдёт.
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Ломать ли совместимость в недокументированной области
Здравствуйте, IT, Вы писали:
IT>Плох тот язык правила которого так легко нарушить.
Ну не надо ставить в один ряд управляемые языки и C — его какбы и делали для того, чтобы сохранить свободу на уровне ассемблера, но упростить рутинные операции.
Если ты помнишь времена Borland C 3.1, то там, например, можно было фактически все — управляемость линкера и компилятора была просто поразительной.
А кому надо жесткие ограничения — добро пожаловать в мир управляемых языков со всеми вытекающими ограничениями.
Re[6]: Ломать ли совместимость в недокументированной области
Здравствуйте, DOOM, Вы писали:
IT>>Я то как раз понял. А ты видимо не совсем. Могу разжевать. Первое дерьмо появилось в 1993 году в функции, которая позволяла себя использовать не по назначению. DOO>Тут уж мильон раз говорили, что нельзя добавлять такую проверку в функцию, которая реализуется одной инструкцией процессора.
Здравствуйте, Шахтер, Вы писали:
Ш>Тут дело даже не в этом. Человек пишет код. У него есть требования на реализацию, кроме того, он должен написать данную функцию максимально эффективно. Ш>Как при этом будет работать данная функция, если её неправильно используют, его волновать не должно совершенно. Как получится, поведение не определено в этом случае.
Разработчики пишут не для себя, а для пользователей/других разработчиков. Если вдруг де-факто оказалось, что недокументированные возможности использует большое количество пользователей, то это повод либо ничего не менять, либо даже ввести недокументированное поведение в стандарт.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Я все же думаю, что компиляторы осторожнее оптимизируют даже стандартную библиотеку и работают с реализацией, а не с названием, какие-то реализации инлайнятся в пару инструкций, какие-то — нет. Вообще, не хочу переходить в сугубо техническую часть, потому что проблема здесь в другом: серьезные изменения были внесены через попу. Нужно было: а) провести анализ и понять как много продуктов валятся, принять взвешенное решение; б) объяснить свою мотивацию пользователям; в) о breaking changes следовало бы информировать заранее.
Если нам не помогут, то мы тоже никого не пощадим.
