Энди провела последние два года, отлаживая GDI в kernel debugger, а это один из суровейших экспириенсов в нашей графике. GDI, во-первых, хрен отладишь, а во-вторых, когда найдешь баг, все равно нельзя ничего править, потому что каждый баг GDI уже behavior.

http://blog.gamedeff.com/?p=93#more-93

я нихрена не понял, но....

>Новая версия memcpy() на некоторых процессорах при некоторых условиях копирует регионы от конца к началу, а при других условиях - от начала к концу
добавить четвёртый, предупреждающий memcpy(dst, src, size,shit!), который при заднем ходе предупреждает о пересечении?
А ещё весьма интересно послушать мнение АМД по этому поводу. Если Штеуд захотел ускорить Свои процессоры, или сделать такой хороший вброс, то не может быть, чтобы у конкурента не было своего мнения по этому поводу. Хотя АМД сейчас пилят какую свою под_архитектуру.

2. А чо они везде не могут использовать memove? Слоу он сейчас явно не будет. Чай 2011 год на дворе. Или железные лентяи оставили где то bottle neck?

Это ты путаешь, что было с тойотой.

Тойота - не пользователь в отношении своих машин. Она - вендор. Когда она выпустила продукт с косяком, она отозвала назад все косячные машины и исправила косяки.

Точно так же интел заменял кривые процы.

Я же .. как раз про вендора который пишет ПО

Еще не давно ты был про вендора, который выпускает кривое железо. Путаешься в показаниях.

> 2. А чо они везде не могут использовать memove?

Затем, что в 99% случаев он не нужен.

>люди не могут поменять memcpy на memove то и флаг им в руки.
В смысле там кого то в Адобе заломало?

>она быстрее.
Дак, где быстрее? Везде? Или только на 80086 камне, где было какое то бутылочное горлышко конвейеров, но сейчас его нету?

В целом согласен, но blender ты явно не использовал

>Затем, что в 99% случаев он не нужен.
Вопрос, не в том что нужно, а в том, что правильно и не принесёт вреда. Потерпевший знал что непалёной водки не бывает? Зачем тогда потреблял? Тем более в общественном месте. Небось и физический вред третьим лицам успел причинить.

ээ

>новая реализация memcpy
это ту, что предлагает интел?

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

Если согласиться с Линусом, то потом, когда найдется еще один кусок индусокода, опять прогнутся под него и так далее. В итоге все скатится к винде, где не microsoft вносит в ОС патчи, исправляющи ошибки в чьих-то поделиях

s/где не microsoft вносит/где microsoft вносит/

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

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

Самое разумное это адобовцам открыть багзиллу и перестать играть с причинным местом.

Они оба ошибаются... потакать бредокодерам нельзя, терять юзверей нельзя.

Я в ужасе что мой вариант в самом низу списка (за Дреппера). Если современное OpenSource сообщество так относится к нарушениям стандарта, то это ж кошмар. Стандарт (и документация на интерфейсы) это священный грааль программирования. Нарушающих его (адобе в данном случае) жечь калёным железом. Поддерживающих его (Линуса) подвергнуть публичному порицанию.

Код писать по стандарту!

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

Если memcpy больше не нужна, обхявить deprecated в новом стандарте и убрать в следующем. Патчей «под адоб» не писать!

Моя всё сказала.

> Функция, в описании которой присутствует уб небезопасна, от таких функций следовало бы избавляться.

Может еще и математикам сказать, что раз на ноль делить нельзя, то их математика неполная и от нее надо избавляться?

>мне фиолетово и перпендикулярно. лишь бы работало, а философия побоку.
Вон на винфак! Если все так будут делать, к третьей версии ядра будут батюшку вызывать - помолиться за «авось заработает» и стабильность
END USER не должен определять стандарты таким образом. Тут проблема была ещё до него. Пусть и решается на соот. уровне программистов. Это не юзерская бага отдельного программиста, а бага всего уровня? Или всё таки адобе?

>Да элементарно - спор о том в какую сторону удав^W память длиннее - от начала к концу или от конца к началу. Некоторые тут правда отстаивают точку зрения, что должно быть одинаково, но их называют идиотами, так как стандарт гласит, что память лучше вообще ни в какую сторону не мерять...

Пусть будет Круглая!

А давайте соберём для адобе отдельный глибц???

Проголосовал против малаграматных полудурков, которых мама в детстве не научила читать стандарты.

это ту, что предлагает интел?

Это та, что уже пропихнута ими в Glibc.

+1 за посылание флеша лесом

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

А давайте поменяем микрокод и вообще перевыпустим все процессоры, на которых memcpy работает якобы «неправильно»?

Звучит бредово, не правда ли?

Я на стороне Ульриха. Есть чёткие определения, есть ошибки в приложениях. В glibc, как и процессорах, ошибки нет. Зачем в них добавлять костыли?

возвращайтесь в реальный мир поскорее, нам тут рабочих рук не хватает

оба правы же
а)стандарты менять не нужно
б)оверлеп не нужен

Можно конечно же исправить memcpy и в дальнейшем подстраиваться под любые баги, которые допустят разработчики прикладного ПО. Потом можно будет через несколько лет с улыбкой читать истории про то как программисты из Micros^W FSF подстраивались под чужие баги и жаловаться на то какой запутанный и громоздкий код они пишут.

Вы все дураки и не лечитесь!! memcpy работает корректно согласно спекам, это азбука для каждого ц-быдлокодера, об этом в любой мурзилке написано. Линусу со своим «стабле апи из нонсенс» стоило бы в данной ситуации язык в жопу засунуть. Если кто-то использует в недоассемблере-ц memcpy, чтобы переслать 13 байт, то это явно не потому, что он хочет использовать memmove. Горите в самой жопе ада, быдлокодеры! Пишите там неуловимые блондиночные косяки на питоне, придурки кривоголовые. Чем радикальней будут разработчики(это касается и gcc), тем меньше говнокода мы увидим в будущем.

я не в курсе событий

кстати, я правильно понимаю что весь патч для быдлокодеров из адобе будет выглядеть как #define memcpy memmove ?

Да, именно так

>Еще не давно ты был про вендора, который выпускает кривое железо.

Вендор, особенно кетайский, собирает свои поделки из готовых компонентов а не производит их все сам. Как например тот же самый Apple

А мне импонирует подход Apple где и memcpy и memmove _ОБА_ алиасы bcopy а про флеш Жобс всё давно сказал :))

CONFORMING TO 4.3BSD. This function is deprecated (marked as LEGACY in POSIX.1-2001): use memcpy(3) or memmove(3) in new programs. Note that the first two arguments are interchanged for memcpy(3) and memmove(3). POSIX.1-2008 removes the specifica‐ tion of bcopy().

Как они могут быть алиасами, если порядок аргументов не такой?

Имя vs Фамилия.

А почему в опросе имя Торвальдса противопоставлено фамилии Ульриха?

>Как они могут быть алиасами, если порядок аргументов не такой?

А ты попробуй подумать :)

А ты попробуй называть вещи своими именами

Тогда код под винду вообще не может быть правильно написанным. :-D

http://www.opensource.apple.com/source/gcc/gcc-5479/libiberty/memmove.c

Это не алиас, а wrapper.

Вот из-за таких «додумывателей», как ты, трактующих всё, как им нравится, подобные проблемы и появляются.

>Это не алиас, а wrapper.

Суть та же :)

Я за Дреппера. Нашли багу во флеше, молодцы.

(Лично у меня в основном 64-х битные системы, если флеш на них перестанет работать --- мне даже лучше, отквлекаться не буду)

Прочитал спор и просто охренел. Разработчикам Glibc реально н**рать на пользователей. Поломали то что работало и отказываются фиксить. Правильно сделал Debian когда свалил на eglibc. +1 за Линуса, только у него есть здравая позиция (THE USER DOESN'T CARE!).

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

Если смотреть глубже, причина проблемы видится в том, что слишком много программистов обладают скорее естественнонаучным (если вообще научным), чем математическим мышлением. Программист должен быть математиком.

Линуса. Пользователь библиотеки функций не должен быть озабоченным об устройстве memcpy.

Дреппер прав. Косяки должны быть исправлены, а не становиться нормой.

>Программист должен быть математиком.

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

Дальше, что stdlib, что С, разрабатывались с помощью инженерного подхода, в твоей терминологии «естественнонаучного». И требовать от участников процесса чего-то другого — глупо.

Более того, сложно сказать, применим ли научный подход для разработки программного обеспечения. Взять тот же хаскель. С одной стороны в его основе лежит FC-System, с другой — в его реализациях огромное количество компонентов, созданных с помощью инженерного подхода. Его система типов не гарантирует отсутствие рантайм-ошибок. Да и программы на нем пишутся вполне себе в традиционном стиле.

> в первую очередь программист должен быть экспертом предметной области.

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

GLibC давно пора отправить на помойку.

> Вендор, особенно кетайский, собирает свои поделки из готовых компонентов

Какая разница, откуда он их берет? Раз накосячил - пусть исправляет.