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

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

Ну, фактически ведь получается что он определен, только не в стандарте, а в его реализации. Вот так и используют.

или же неопределен. Как в случае glibc

Библиотека — не особенность ЯП, а просто реализация. Можно ее форкнуть, не меняя сам ЯП.

Библиотека — не особенность ЯП, а просто реализация. Можно ее форкнуть, не меняя сам ЯП.

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

https://en.wikipedia.org/wiki/C_standard_library#Standardization:

Over time, user communities of C shared ideas and implementations of what is now called C standard libraries.

Many of these ideas were incorporated eventually into the definition of the standardized C language.

или же неопределен. Как в случае glibc

Всмысле? glibc — это реализация стандарта, и она содержит вполне себе определенный код. Я могу посмотреть как именно в ней реализовано поведение memcpy при копировании перекрывающихся областей и использовать это в свою пользу, этакий хак.

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

Допустимые аргументы - это те, которые задокументированы.

На первом курсе учат делать проверки и обрабатывать исключения

А читать документацию - на втором, но ты до него не доучился?

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

его сделали те, кто должен был его сделать — инженеры из intel. Memcpy(3) изначально переносила данные так, как ЕЙ было удобнее, если это имеет значение КАК переносить, то нужно юзать memmove(3), которая переносит данные ВСЕГДА правильно, даже если они перекрываются. Memcpy(3) так НЕ делает, и ПОТОМУ работает быстрее. Потому-что переносит в том направлении, в каком БЫСТРЕЕ на ЭТОМ процессоре.

Потому нет ничего удивительного в том, что инженеры intel поменяли направление на более быстрое. Это их работа. Они *должны* были это сделать.

А быдлокодеры из адобы *должны* были читать ман: «The memory areas must not overlap. Use memmove(3) if the memory areas do overlap». Какая буква тут непонятна?

ЗЫЖ а Линус... Вообще-то, это не его дело. И его мнение тут не весомее моего или твоего.

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

типичный must die way.

Через LD_PRELOAD можно подменить memcpy на неиспорченный? Если да, то проблема в общем-то решаема на уровне головной боли мейнтейнеров дистра.

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

на практике часто решения в комплексных числах имеют важный практический смысл. Если по проводу течёт реактивный ток, то счётчик не крутится, и энергия не уходит от генератора к нагрузке. Но ток течёт, и провод греется. Стрелка амперметра отклоняется.

В конце концов, основная теорема алгебры гласит, что у любого уравнения второй степени ДВА корня.

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

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

Функции это черный ящик с инструкцией.

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

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

А практика говорит, что оно рано или поздно НЕИЗБЕЖНО изменится.

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

ты уже научился делить на ноль?

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

кстати — у меня выбрасывает. И документация описывает всё, кроме UB.

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

всё правильно. Если ты не уверен — убейся ап стену.

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

ВПИСАНО ДАВНО УЖЕ. И в Linux Programmer's Manual, и в MSDN.

Это, блжад, АЗЫ!

Я тебя этому пытался научить еще в другом треде (или Эдику, я вас всегда путаю), но ты видимо так и не понял. Марш на рынок за учебником математики.

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

ты не понимаешь — на том уровне проверка слишком ДОРОГА. Потому-то быдлокодеры и сэкономили на проверке, которая есть в memmove(3). На спичках.

На самом деле, перекрывающиеся области копировать можно точно также, единственный нюанс — если они перекрываются «вниз», надо их «сверху» копировать, что-бы данные сами себя не затирали. Всего-то делов — проверить разницу, и копировать наоборот. Так и делает memmove(3), которая на 3 такта медленнее из-за этого. (точнее, она намного медленнее в случае обратного копирования большой области из-за невозможности кеширования, однако это не играет роли, потому-что memcpy(3) в данном случае всё только портит, и вообще НИКАК не работает).

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

классический флейм здесь — сборщик мусора. Из-за чего, я его в частности и недолюбливаю, ибо тормозит сильно. Причём тормозит ВНЕЗАПНО, в продакшене. А в тестах всё хорошо.

Вот когда GC хочет заткнуть дырку где был мусор, он сдвигает кусок «назад». Или передний кусок «вперёд». Кеш обычно предвыборку делает, т.е. читает «вперёд», а вот GC этого «не знает», точнее «знает», но неточно. Ибо размер кешей и их организация разная на всех процессорах, и невозможно сказать, что будет выгоднее, копировать 30 байтов «вперёд» или 5 байтов «назад». IRL лучше вообще никак и никуда не копировать ИМХО. Это надёжнее и быстрее, как не странно.

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

/0

а если серьёзно, таких команд полно.

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

ну да. А ещё можно x-- - --x;

Через LD_PRELOAD можно подменить memcpy на неиспорченный? Если да, то проблема в общем-то решаема на уровне головной боли мейнтейнеров дистра.

это идиотизм. Memcpy тупо БЫСТРЕЕ. Предлагаешь тормозить ВСЁ из-за какого-то говнокода?!

Я тебя этому пытался научить еще в другом треде (или Эдику, я вас всегда путаю), но ты видимо так и не понял. Марш на рынок за учебником математики.

в моём было написано UB. А что, теперь наука этот вопрос решила?

А, ну тогда понятно. Если это действительно такая фича ради скорости, то ССЗБ те, кто ее использовал.

Предлагаю тормозить конкретно флеш.

Наука этот вопрос решает еще на первых двух курсах технического ВУЗа.

Если это действительно такая фича ради скорости

и там и там rep movs. Только memmove сначала проверяет, а потом копирует. А memcpy НЕ проверяет. Потому чуть быстрее.

Обычно в процессорах ВСЕГДА быстрее копировать «вперёд». «Обычно» это НЕ всегда. «Поломка» как раз и связано в том, что быдлокодеры адобы надеялись, что «обычно» == «всегда», и что «лишь-бы работало на моём локалхосте, а на других насрать».

Конец немного предсказуем...

Предлагаю тормозить конкретно флеш.

да вроде там не только с memcpy(3) косяк. Memcpy(3) это только то, что нашли. Была-бы проблема только в этом, в адобе давно-бы исправили.

Наука этот вопрос решает еще на первых двух курсах технического ВУЗа.

это что за вуз такой, где на ноль делят? Ты скажи, страна должна знать в лицо своих героев.

на практике часто решения в комплексных числах имеют важный практический смысл.

С самого начала я написал, что ф-я работает на множестве вещественных чисел

и там и там rep movs.

Нет нет. Там довольно сложный код

С самого начала я написал, что ф-я работает на множестве вещественных чисел

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

Ну или пусть корень из модуля считает, ибо для второй степень ответ отличается лишь углом, который для отрицательного аргумента составляет +-pi/4 AFAIK

Нет нет. Там довольно сложный код

я знаю, что сложный. Ибо перенести 1,2,3,4... байта быстрее не rep movs, а как-то по другому. И это сильно зависит от CPU. В итоге там Over9000 маленьких кусочков отдельно для AMD-K8.4534 и 3х байтов, и далее по списку. И ещё это от выравнивания зависит, нечётные байты сдвигаются как-то иначе на некоторых CPU, чем чётные. Впрочем, все эти оптимизации к нашему спору отношения не имеют.

Исходный и целевой регионы не должны перекрываться.

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

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

оператор деления "/", делитель не должен быть равен нулю.

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

А если бы результат обработки пересечения регионов был бы определенным - а именно функция отказывалась работать и выдавала ошибку, то никто бы и не использовал memcpy таким способом.

В стандарте не должно быть UB

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

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

почему всегда users, why not packages maintainers?

В итоге там Over9000 маленьких кусочков отдельно для AMD-K8.4534 и 3х байтов, и далее по списку.

И если добавить к эти Over9000 кусков, которые явно в рунтайме как то перебираются, еще парочку, задача которых определить пересечение и c-jmp-ить на memmove, то мир рухнет ?

Почему то при делении на ноль мы получаем ошибку деления на ноль, а не некое рандомное число

возьми double, и получишь то, что хочешь.

#include <stdio.h>

int main(int argc, char *argv[])
{
	double x = argc - 1;
	double y = x;
	printf("%f/%f=%f\n", x, y, x/y);
	return 0;
}

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

а он и есть определённый — разница размножается по памяти. Т.е. функция memcpy(3) работает как memset(3).

а именно функция отказывалась работать и выдавала ошибку

вот memmove(3) отказывается работать неправильно, но не возвращает ошибку, а работает правильно.

В стандарте не должно быть UB

почему в мире есть UB, в математике есть UB, а в CS его «не должно быть»?

Что то в последние годы все чаще стало это проскакивать в качестве аргументации

Это быдлокодеры так оправдывают себя. Ведь сказать «пользователя не волнует почему сломалось» звучит гораздо более красиво, чем «мы сделали говно которое по странному стечению обстоятельств работало, но потом оно сломалось, так что верните всё как было, потому что мы быдлокодеры и не знаем как сделать правильно, а гордость не позволяет нам признать что мы говнокодеры»

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

деление double/double тоже успешно завершается без ошибок, выдавая результат -nan. Чем ты недоволен? Да, это на моём Atom N270. На твоём CPU оно может дать что-то другое, если твой CPU не стандартный, и не хочет следовать IEEE754. Выкинь свой комп на помойку.

Те кто так трясутся от потери скорости на паре сравнений, вполне могут реализовать свою memcpy

о том и речь.

И если добавить к эти Over9000 кусков, которые явно в рунтайме как то перебираются, еще парочку, задача которых определить пересечение и c-jmp-ить на memmove, то мир рухнет ?

в memmove свои Over9000 кусочков. Которые правильно работают не только когда области НЕ перекрываются.

Это быдлокодеры так оправдывают себя. Ведь сказать «пользователя не волнует почему сломалось» звучит гораздо более красиво, чем «мы сделали говно которое по странному стечению обстоятельств работало, но потом оно сломалось, так что верните всё как было, потому что мы быдлокодеры и не знаем как сделать правильно, а гордость не позволяет нам признать что мы говнокодеры»

ППКС.

И если добавить к эти Over9000 кусков, которые явно в рунтайме как то перебираются, еще парочку, задача которых определить пересечение и c-jmp-ить на memmove, то мир рухнет ?

Дополнительные инструкции нужно добавить в моск программистов, которые не в состоянии сначала читать, а потом делать.

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

Так вроде она и так на ассемблере и она как раз для тех, кто трясется от потери скорости. Для остальных есть memmove

А являются ли user'ами те, кто сам ничего не вкладывает в мир СПО? Или же это крысы, подбирающие объедки со стола?

Пользователи СПО — крысы, подбирающие объедки со стола. Очень удачная характеристика, записал.

Так вроде она и так на ассемблере

И как она переключает варианты оптимизации между разными процами ?

и она как раз для тех, кто трясется от потери скорости.

Сильно сомневаюсь что потеря тактов на двух сравнениях заставить их трястись еще больше

Для остальных есть memmove

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

выдавая результат -nan. Чем ты недоволен?

memcpy не выдает аналога "-nan" - вместо этого она грозит пальчиком в документации, и предписывает творить UB в реализации.

UB не место в стандарте.

почему в мире есть UB, в математике есть UB, а в CS его «не должно быть»?

Не знаю, есть мнение что КЭП тут бессилен, если тебе это не очевидно.

Компы - вообще то детерминированные творения.