Откуда это «user don't care»?

Я написал функцию «константа» вот такого вида

возвращает значение затребованной константы, аргумент - имя константы, можеьт быть pi, e или zero

А вот фиг. Твоя функция возвращает значение затребованной константы e или zero, и значение pi в ином случае. Так что это ошибвка документации, и тут виноват таки ты.

Можешь помечать меня как хочешь, но я не понимаю зачем было лезть в glibc и ломать флеш. Чисто из вредности?

memmove работает намного медленнее, т.к. сама следит за пересечениями.

UB будет тогда, и только тогда, когда НИКТО не будет следить, что области пересекаются. Как в адобе. Когда это сломается — вопрос времени.

Если в функции починили баг, при котором она выдавала неправильный результат — это нарушение обратной совместимости или просто фикс бага? :3

Твоя функция возвращает значение затребованной константы e или zero, и значение pi в ином случае. Так что это ошибвка документации, и тут виноват таки ты.

В документации написано, что для нее множеством допустимых аргументов является {«zero», «e», «pi»}, и для каждого из них она возвращает указаное число. А 3.14159 на «pie» возвращает исключительно конкретная реализация. Но «pie» вообще не входит в множество допустимых аргументов, как отрицательные числа не входят в область допустимых аргументов sqrt, хотя какая-нибудь конкретная реализация что-то конкретное выдаст.

memmove работает намного медленнее

Бенчмарки есть?

Можешь помечать меня как хочешь, но я не понимаю зачем было лезть в glibc и ломать флеш. Чисто из вредности?

его никто не ломал. Memcpy(3) ВСЕГДА обладала этим «багом». И ВСЕГДА этот баг проявлялся если копировать не в ту сторону. В какую именно — зависит от реализации. Если реализация не менялась посл. 7 лет — ничего не значит. ВНЕЗАПНО(для быдлокодеров) — поменялась.

Бенчмарки есть?

есть. Ищи в гугле, или делай сам, для своей текущей glibc.

В документации написано, что для нее множеством допустимых аргументов является {«zero», «e», «pi»}, и для каждого из них она возвращает указаное число.

Именно. Но если мы посмотрим на функцию, мы увидим, что это не так. Никакой проверки на допустимость нет, никакого упоминания аргумента «pi» тоже нет. Документация врет, поэтому пользователь основывался на фактической работе функции.

как отрицательные числа не входят в область допустимых аргументов sqrt, хотя какая-нибудь конкретная реализация что-то конкретное выдаст

http://docs.oracle.com/javase/6/docs/api/java/lang/Math.html#sqrt(double)

Смотри-ка, абсолютно все случаи описаны. Слабо так сделать?

В случае с memcpy результат был всегда правильный — память копировалась.

В случае, если функция действительно с багом, зависит от того, пользовался ли кто-либо багом.

Я не про memcpy, я про термин обратной совместимости в общем.

В случае, если функция действительно с багом, зависит от того, пользовался ли кто-либо багом.

Т.е. нарушение обратной совместимости — термин, зависящий от количества пользователей бага?

его никто не ломал

Как это никто? А тот злополучный патч, от которого Торвальдс матюками всех обложил, кто сделал?

В принципе да. http://xkcd.com/1172/

И что ты думаешь во про такую функцию my_sqrt()? Она ведь для отрицательных чисел тоже что-то пишет

#include <stdio.h>

#define abs(x) ((x)>0?(x):(-(x)))

double my_sqrt(double x)
{
        double res = 1;
        int i = 0;
        while (abs(x - res) > 0.2 && i < 100)
        {
                res = (res + x/res)/2;
                i++;
        }
        return res;
}


int main(void)
{
        printf("sqrt(16) = %lf\n", my_sqrt(16));
        printf("sqrt(-16) = %lf\n", my_sqrt(-16));

        return 0;
}

~

Что сказать-то хотел? УГ и я могу написать. Как это доказывает, что можно делать изменения в недокументированном быдлокоде?

И то, и другое. И надо смотреть, что меньше вредит. Возможно, приделывать костыли, чтобы работало и по-старому, и по-новому.

Это не УГ, это грамотная функция поиска квадратного корня положительного числа. В качестве аргумента принимает положительное число типа double.

А вот что она сделает при отрицательном аргумента - чистейшее UB. И никакого «более-менее» корректного поведения тут не сделать.

И никаких технических причин сохранять my_sqrt(-16) = -3.859442 в ходе дальнейших улучшений нет.

Например, если я решил, что нет смысла ограничивать 100 шагами цикла, а можно 1000, то получаю my_sqrt(-16) = -15.842310

Или перепишу условие цикла

while (abs(x/res-res) > 0.2 && i < 100)

Но при этом всякие Адобаси Долбаковы оказываются в пролете

А вот фиг. Твоя функция возвращает значение затребованной константы e или zero, и значение pi в ином случае

Нет. Функция делает в точности то, что написано в документации.

В спецификации сказано - допустимы ТРИ варианта входного аргумента. Для каждого из них функция возвращает определенное значение. Функция реализует эти требования в полном объеме, значит функция соответствует спецификации.

Всё твои предположения о том, что функция возвращает в остальных случаях - домыслы.

Для memcpy() сказано - копирует регион памяти. Исходный и целевой регионы не должны перекрываться. Всё, эту функцию НЕЛЬЗЯ использовать в случае перекрытия регионов. Вне зависимости от реализации. Попытка опираться на UB - это говнобыдлокод. Тот кто опирается на UB - говнобыдлокодер.

Но если мы посмотрим на функцию, мы увидим, что это не так.

А ты не должен «смотреть на функцию». Ты должен смотреть на ДОКУМЕНТАЦИЮ. Потому, что не можешь даже предполагать, что функция сделает при нарушении документации. Потому, что она имеет право на всё что угодно - от игнорировать ошибку и вплоть до трапнуть программу по SIGKILL и отправить систему в poweroff.

Никакой проверки на допустимость нет, никакого упоминания аргумента «pi» тоже нет.

В документации описано. Документации соответствует. Всё.

Документация врет, поэтому пользователь основывался на фактической работе функции.

Документация не врёт. В документации полностью опиcаны допустимые аргументы. Функции это черный ящик с инструкцией. Всё что не описано в инструкции, имеет право измениться в любой момент. Этому вообще-то на первом курсе учат.

Потому, что она имеет право на всё что угодно - от игнорировать ошибку и вплоть до трапнуть программу по SIGKILL и отправить систему в poweroff.

Про защиту от дурака мсье не слышал? UB не должно быть ни при каких обстоятельствах. Точка.

В документации полностью опиcаны допустимые аргументы.

Нет, не описаны. Допустимые аргументы — это те, при которых функция выдает результат. Твоя функция выдает результат при любых аргументах, значит и допустимы все.

Этому вообще-то на первом курсе учат.

На первом курсе учат делать проверки и обрабатывать исключения, чтобы UB не было. Но видимо, не везде учат. Или не всех.

А вот что она сделает при отрицательном аргумента - чистейшее UB.

Вот именно, поэтому функция и УГ.

И никакого «более-менее» корректного поведения тут не сделать.

В нормальных функциях для этого есть особый вид результата (не число) или исключение. Пример был выше.

Про защиту от дурака мсье не слышал? UB не должно быть ни при каких обстоятельствах. Точка.

Я тебе привел прекрасную функцию извлечения квадратного корня, которая при отрицательных аргументах выдает UB.

И никуда от этого не деться, такова природа квадратного корня, что в рамках вещественных чисел извлекать корень из отрицательного нельзя

для этого есть особый вид результата (не число) или исключение.

Ну могу я вписать exit(1);

А лучшая (и на самом деле единственная) защита от дурака - не пускать дураков за компьютер.

Я тебе привел прекрасную функцию извлечения квадратного корня, которая при отрицательных аргументах выдает UB.

Выдавать UB уже некорректно.

И никуда от этого не деться, такова природа квадратного корня, что в рамках вещественных чисел извлекать корень из отрицательного нельзя

Выдавать результат нельзя != можно выдавать неопределенный результат.

А лучшая (и на самом деле единственная) защита от дурака - не пускать дураков за компьютер.

Верни аттестат в школу, быстро, решительно! Читающим термины буквально не месте в разработке.

Читающим термины буквально не месте в разработке.

Как раз именно их код и оказывается в итоге наиболее безопасен. потому что они не лезут со своими «а я знаю, как оно внутри» и не полагаются на особенности конкретной реализации.

Их код вообще нигде не оказывается, потому что при любом нестандартном юзкейсе все пищит и портит.

потому что при любом нестандартном юзкейсе все пищит и портит.

Используешь код не в соответствии с документацией - ты ССЗБ. Что же до «пищит и портит», то наиболее адекватный способ реагирования на заведомо неправильные аргументы - как раз попищать и вырубить программу.

Используешь код не в соответствии с документацией - ты ССЗБ.

В идеальном мире, где документация описывает все и компилятор выбрасывает ошибки при нарушении документированного юзкейса — так и есть. А в нашем мире — увы.

наиболее адекватный способ реагирования на заведомо неправильные аргументы - как раз попищать и вырубить программу

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

где документация описывает все

В случае с memcpy так и есть, хотя, конечно, им следовало жирными буквами вписать в стандарт «НЕЛЬЗЯ ПОДСТАВЛЯТЬ ПЕРЕСЕКАЮЩИЕСЯ РЕГИОНЫ»

Они зачем-то написали UB.

Им следовало поставить проверку и выдавать хотя бы -1 (или что там в сях принято для таких случаев). Тогда проблем бы не было ни у кого.

Им следовало поставить проверку

Зачем? Я не представляю, как можно проглядеть, что источник и приемник находятся в пределах одного массива, а других способов заиметь перекрывающиеся регионы мне неизвестно.

Я не представляю, как можно проглядеть, что источник и приемник находятся в пределах одного массива, а других способов заиметь перекрывающиеся регионы мне неизвестно.

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

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

Это не повод лишать все языки программирования их уникальных возможностей.

Я разве что-то говорил по поводу уникальных возможностей?

Давайте еще в архитектуры различных процессоров добавим всевозможные проверки — ведь люди ошибаются.

Я разве что-то говорил по поводу уникальных возможностей?

А разве я что-то говорил о том, что ты что-то говорил о уникальных возможностях?

Если ты весь такой идеальный и пишешь код без ошибок,

Если я вижу, что в источнике и в приемнике стоит один и тот же массив, я использую только memmove

Это не повод лишать все языки программирования их уникальных возможностей.

К чему это было?

Разве какие-то команды процессора выдают UB?

Разве какие-то команды процессора выдают UB

Да, в reserved битах некоторых регистров может быть что угодно. И когда ты ты с этими регистрами имеешь дело, ты не можешь рассчитывать, что там 0. И если ты попробуешь эти биты изменить, может случиться нежданчик.

И когда ты ты с этими регистрами имеешь дело, ты не можешь рассчитывать, что там 0

Печально конечно. Но то железячники, они привыкши. Там и говнокод писать незазорно, потому что он все равно нечитабелен.

Но то железячники, они привыкши.

Так может и у нежелезячников надо привычку вырабатывать писать по стандартам?

Стандарты тут ни при чем. Просто у железячников везде такой бардак, поэтому они волей-неволей привыкают проверять каждую строчку кода и искать баги месяцами. А другие люди могут обойтись без этого, если кое-кто не будет писать говнокод и фапать на стандарт. Но зачем, ведь можно потратить несколько дней на срачи с пользователями. Написать 3 строки проверки — это не наш метод, мы положим жизнь за стандарт.

Это не повод лишать все языки программирования их уникальных возможностей.

К чему это было?

К тому, что возможность использовать memcpy для копирования пересекающихся областей памяти — по своему уникальна. Далеко идти не надо, Flash Player тому пример. Другой же вопрос, насколько правильно использовать подобный хак в таком популярном софте как Flash Player.

При чем тут язык программирования? Это же функция из библиотеки.

К тому, что возможность использовать memcpy для копирования пересекающихся областей памяти — по своему уникальна.

Так если поведение неопределенное, результат тоже будет неопределенным. Ка кэто можно использовать, если не нужно создать треска?

А другие люди могут обойтись без этого, если кое-кто не будет писать говнокод и фапать на стандарт.

Другие люди вполне себе могут использовать языки программирования, в которых подобные опасные штуки проверяются.

Разве какие-то команды процессора выдают UB?

Не UB, но скопирует одну область памяти поверх другой, и даже не заикнется:

rep movsb

Как ты считаешь, стоит и тут добавить аварийное завершение или что-нибудь подобное? Ведь люди ошибаются.

Это же функция из библиотеки.

...языка программирования.