Уровень программистов

О тестировании функций
На одном форуме, где в основном зарплата пишущих 2К5Б и выше, встрял на свою голову в диспут о тестировании функций.
Я просто спросил, сколько надо сделать проверок для функции на С++ вида

float funk(float f);

Варианты были разнообразные, и неинтересные. Интересно другое, никто из порядка 10 программистов не сказал, что для этого надо код функции посмотреть.

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

float funk(float f) {
float ff;
// чего-нибудь 1
...
memcpy(ff,f,sizeof(f));
// чего-нибудь 2
...
return ff;
}
Вопрос тот же, сколько надо сделать проверок для этой функции?
К сожалению, судя по комментариям в топике habrahabr.ru/...​blogs/development/116468
с правильным ответом опять будут проблемы.

Кроме того, правильный ответ будет зависеть не только от операционки, библиотеки, компилятора, но и от процессора. И даже на разных х86 ответ будет разный. Например, AMD или Intel. И кстати, на 64 бита проверок надо больше, чем 32.
А ведь есть ещё ассемблерные команды вычисления адреса перехода!

К тому же, при работе прерываний во время исполнения функции memcpy или других ниток в переменной f могут произойти неожиданные изменения. То есть, даже при автономной проверке ошибка в программе может маскироваться другой ниткой или прерыванием, не верите?
Однажды такое было на практике.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Привет знатокам английского!

Я просто счастлив, что такие, как Вы, считает меня троллем. Как говорится, успеха не прощают.

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

тут все правильно?

memcpy(ff,f,sizeof(f));

может имелось ввиду это:

memcpy(&ff,&f,sizeof(f)); ???

Уважаю, хоть один трезвый с зарплатой 2К5В.

Но всё таки, ответьте на вопрос, как полностью оттестить приведеный код?

Странное поведение топикстартера, мягко говоря, если тело функции неизвестно, то там может быть вполне и такое:

float func(float f)

{float ff;

{

float* f=new float;float* ff=new float;

memcpy(f, ff, sizeof(ff));

}
return ff;
}

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

Извините, если что.

Тут второй трезвый нашёлся ниже.

Я ж говорил — код на переделку и ошибка в ДНК :)Но даже если так, то что правильно:

memcpy(&ff,&f,sizeof(f));

memcpy(&ff,&f,sizeof(ff));

«Супер-пупер-хакеры» еще и мин/максы тут прикрутят.Кто-то может вспомнит и о memcpy_s ... это хоть куда б ни шло.

Но использование memcpy для копирования значений к С++ отношения не имеет, вернее противопоказано, ибо если иметь в виду ЛЮБЫЕ типы, то начинаются спецэффекты.

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

Замечательно, два трезвых на ДОУ.

Уважаемый юрист VVS, давайте перепишем пример так:

float funk(float f) {
float ff;
char s[10],d[10];
// чего-нибудь 1
...
memcpy(d,s,10);
// чего-нибудь 2
...
return ff;

Только к десятке не придирайтесь, пожалуйста. И будем считать, что стек велик и не разрушается от выделения памяти для локальных массивов длиной 20 байт.
Но кто-нибудь сможет сказать, как же правильно протестить функцию?

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

Я отвечал на вопрос «как протестировать программу» а не что в ней неправильно. СОгласен, я не ожидал от тебя такого дешевого трюка, поэтому пробежал програму вскользь глазами и не заметил ошибки. Ну а зарплату в $2.5к я пеперос пять лет назад.

Уважаемый reality_hacker!
Не обижайтесь пожалуйста!
Топик написан 1 апреля,
к тому же у Билла Гейтса зарплата всё равно больше Вашей, и ошибок в известной ОС ещё больше.
К тому же выражение

подсунуть мок

мне не удалось расшифровать. Сдаюсь.

Но по поводу тестирования смотрите ниже.

О, так тебе нужно заниматься серьезным ликбезом в плане тестирования перед написанием таких топиков: en.wikipedia.org/...iki/Mock_object

В процедурном программировании аналогичная конструкция называется «dummy» (англ. — заглушка).

Спасибо за совет

«дамми» — это кукла, т.е., в случае программирования, эмуляция/пустой код, итд. А заглушка — это «стаб».

Стаб-функции часто содержат внутри дамми-код.

Смотрите ниже

Но кто-нибудь сможет сказать, как же правильно протестить функцию?

Проверка одна, вернее ее вердикт %) -> переделать.
Ибо там однозначно ошибка в ДНК.

За такой код поубивал бы...

Уважаемый Директор в Cinegy Systems LLC!

Читайте комментарии ниже.

Там много чего написано. Вас смутило, что я резко высказался о качестве именно такого кода? Так я еще раз подтверждаю — такой код мина замедленного действия и писать ТАК нельзя, особенно в крупных проектах или которые живут дольше, чем время «жизни» одной версии компилятора/платформы..

Особенно мне нравятся обсуждение высоких материй при:

а) ошибка в коде (хоть один догадался);б) заложенная мина (даже если код с &)

Уточните плз, куда и зачем меня послали %) (ПС: С++ был моим основным языком лет надцать, пока не стал другой язык — язык, которым написан НКУ).

ПС: комментарии я прочел все, но моего варианта ответа на время написания моего ответа не было.

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

Вы предлагаете работу за 2К5Б?

Какие могут быть изменения, если ff и f на стеке?

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

Это уже проблемы платформы.

Так в любой платформе есть проблемы, например в Линуксе (см. ссылку на memcpy), и сколько их там ещё?

Это не проблемы платформы. Ребята из intel’а правы, во всех стандартах поддерживаемых OpenGroup сказано что поведение undefined. И формально и по сути они правы. Есть bcopy() и memmove(), есть альтернатива скорости определённому поведению. Линус не прав.

Проблемы платформы — это когда процесс имеет доступ к памяти другого процесса даже в результате сбоя. Потокам нужно выделять свой собственный стек, etc, etc, etc. Существует ряд несложных правил, которые помогут избежать больших проблем в коде.

Потокам нужно выделять свой собственный стек, etc, etc, etc

Во первых наглючить можно и не в стеке.

Во вторых уровень программистов с зарплатой 2К5Б очевиден.

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

И кто там виноват, понятно: программисты.

Вот ещё выяснится, сколько ошибок в лазерном прицеле из-за memcpy, или в стиральной машине.

Как можно наглючить не в стеке, если в примере они в стеке? Да не важно даже в чём можно наглючить, есть константные данные процесса и потока, есть динамические. И в том и в другом случае платформа должна обеспечивать возможность изоляции этих данных, что большинство современных платформ и делает.

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

Чем Вам не угодили программисты с entry level 2K5Б зарплатами?

а что такое 2К5Б? 2килобакса?

скорее 2,5к.. или 2005

Вобщем «кто ясно мыслит — тот чётко излагает» © :)

Кстати про хабр, из чего следует что тамошняя аудитория на 100% состоит из высокооплачиваемых програмистов то?

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

Уважаемый Mike Gorchak!

Теперь понятно

Чем Вам не угодили программисты с entry level 2K5Б зарплатами?

?

6 дней на понимание, не много ли?

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

Потому Делфи жив до сих пор, что были доки на русском.

Но это уже совсем другая история.

Это называется stream of consciousness.

Нет. Это называется потом мыслей.

Именно потом, а не потоком, если Вы ещё понимаете рашен мову.

У флудера даже мысли потоповые.

Ну на ДОУ никто не может тест функции написать, так какие ко мне претензии.
Уровень прогеров чрезвычайно упал. Есть только знание «английских» слов, типа тех,

что Вы меня обозвали. Но суть то не меняется от моих знаний Ваших англицизмов. А по фене это к Янеку.

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

Вы знаете именно тот ответ, который единственно верный, по-Вашему. Но это не имеет абсолютно никакого значения. Значение имеет лишь то, способны ли Вы воспользоваться своими знаниями для своей пользы.

Отвечать просто нечем. Мнения могут быть в истории, в искусстве. В программировании мнения могут быть только у непрофессионалов. Либо ты знаешь теорему Пифагора, либо нет.
Пока я видел только щеголяние английским. А вот описания х86 полного нет до сих пор на русском. Это основной показатель уровня.
О каком уровне программирования может идти речь в этом случае?
И причём тут я со своим топиком?

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

Давай, профессионал, правильный ответ.

Если Вы проверяете ОЗУ (пардон, RAM), для полной проверки Вам надо записать в каждую ячейку, скажем 64 разрядной памяти, все варианты (2 в 64 степени) и прочитать все остальные ячейки, что бы убедится, что на них не влияет запись в текущую ячейку. Итого 2^64*<размер ОЗУ> проверок, что займёт порядочное время. Но вернёмся к нашим баранам.
Для проверки функции, исходник которой Вам не известен, надо хотя бы попытаться найти исходник. Видимо есть бинарник, надо дизассемблировать и проверить все ветки ветвления, все деления на ноль и вообще все места, где могут произойти исключения.
Теперь memcpy. Её входные параметры — выход нашей функции, её возврат — вход нашей функции, такой же как наши входные параметры.
Мы не проверяем memcpy, мы тестируем нашу функцию. Значит надо проверить, что наш выход не нагадит тому, кого вызываем, т.е. memcpy. Если у Вас нет этой проверки, то подлости Федоровцев Вам трудно будет найти, если Торвальдс их не поймает за хвост.
Аналогично, законные возвраты memcpy не должны убить нашу функцию. Это то же надо проверить. А если она сделает незаконный возврат, можно попытаться отловить и пресечь и доложит начальству. Но вряд ли можно предусмотреть любую глупость программистов memcpy, как показывает практика.
И на крайний пожарный случай. Если нечем дизассемблировать, а заказчик пристал. Ну, скажите, что надо проверить функцию при любых аргументах. Подумаешь 2 в 64 степени вариантов, подождёт.

Правда, остались ещё проблемы платформы, но Вы говорите, это их проблемы, но заказчик обычно так не считает. Он скажет: «Ну у других то работает!».

Та да, а еще нужно учесть что иногда космическое излучение может создать электрический заряд в компьютере и поменять значение бита в момент работы функции, поэтому нужно проводить тестирование на сервере под мощным ренгеновским излучением, что бы протестировать и такой вариант тоже. А еще это же излучение может создать заряд в головном мозге, поэтому программировать стоит только в шапочках из фольги goo.gl/q28Dv

Спасибо за подсказку, реал хакеры это конечно круто, но не умно. Для мощного рентгеновского, и гамма, и альфа, и бета применяются аппаратное мажоритирование и горячий резерв. Программно это НЕВОЗМОЖНО. Вот тут много слов, а по сути ноль.

2 Андрей Иванов
простите, а про несостоятельность HTML это писали Вы?
www.developers.org.ua/...ums/topic/2067

«Альтернатива HTML, CSS, JAVA для интерфейса программ on-line »

Вы считаете это бредом?

Всё, что не внедрено, можно считать бредом

так это Вы

www.developers.org.ua/....ums/topic/2067

«Альтернатива HTML, CSS, JAVA для интерфейса программ on-line »

понятно.

Кстати оказывается не все так просто: news2.ru/story/221448

Ваши источники врут, потому что не учили физику в школе.

В стальном лифте FM-радио плохо работает или вообще глохнет,а мобилка прекрасно звонит и ловит WiFi, потому что щели в лифте сравнимы с длиной волны диапазона мобилок и WiFi, но меньше диапазона FM-радио. Поэтому, для того, что бы просканировать мозг, надо длину волны меньше каппиляров кожи, а это почти инфракрасный, который прекрасно гасится атмосферой. Так что разрешаю ходить Вам без шапочек.

Спасибо, поржал :)

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

Согласен с вашим опонентом. Кроме цели задеть разработчиков толку от поста 0.1%.
Вообще все сводится к двум пунктам:
1. Нельзя предусмотреть любую глупость программистов

2. Нельзя протестировать на 100% абсолютные undefined вещи, зависимые от аппаратной плафтормы к тому-же. Такие вещи просто нельзя создавать в этом виде.

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

Брать с Линуса пример и показывать свое ЧСВ, как минимум неприемлемо.

Ну Вы же оторвались от английских букв среди ночи.
И ещё один супер-хакер. Значит толк есть пока.
Лучше всех тестирует дядя Билли уже надцать лет на шару на всём шарике, не думаю что это Ваш идеал тестирования.
Я не говорил, что считаю Линуса умнее Вас.
А вот дайте ссылочку на англоязычную или вообще на литературу, по которой можно по-научному организовать тестирование не оффисного ПО, а хотя бы банковского, про атомные станции уж и не говорю. Я с удовольствием поучусь. Про Кнута с алгоритмами знают все. А по надёжности ПО какая книжка?
Тут же форум ДОУ а не танцы со звёздами!
И что бы был толк, говорить надо не про ЧСВ, а по сути дела.

Особенно впечатляют пассажи

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

Сколько НАДО, столько и занимает. А проценты качества теста (или ПО) — в какой книжке вычитали?
ПО или работает, или нет. Это не процент выхода годных микросхем. ПО не изнашивается.
Согласен, что есть масса заказчиков, которым почти плевать, глючит сайт или нет.
Но если в Линуксе такой бардак memcpy (а может ещё много в чём), куда ж его использовать в серьёзных местах?
И где этот представитель QNX Software Systems?

QNX — это ж клон Ленухи. Айайяй! Продажи то упадут.

>>И где этот представитель QNX Software >>Systems?

>>QNX — это ж клон Ленухи

это еще с какого перепуга ?

Тролль допустил конфуз. Глубоко извиняюсь, склероз. QNX — не клон Ленухи. Но Иксы то есть, и memcpy вместе с ним ;)

Иксов там нет.

Как, уже нет?
Значит врёт Википедия:

«Так появилась QNX4. Она была доступна со встраиваемой графической подсистемой, названной Photon microGUI, и портированной под QNX версией X Window System.»

QNX4 и QNX6 это две большие разницы. Сейчас иксов официально нет.

Да.

Сколько НАДО, столько и занимает

Кому надо абстрактное тестирование в вакууме? Разве что в институте для курсача какого-нибудь.

ЗЫ: забыл протестировать на задымление и уровень влажности. Ведь если в датацентре не соблюдаются параметры среды то вычислительная система может давать сбои.

Извините за оффтоп про задымление.
Дело в том, что если в бите 0, обычно больше потребление ячейки памяти, потому что полевой транзистор открыт и течёт ток. Когда перешли на 64 бита (например Vista), а float остался 32- битовым, мало того, что около 30% памяти «гуляет», она ещё и жрёт прилично. Кстати в 7-ке вроде пофиксили. Так что тесты на потребление энергии для ПО проводятся уже десятилетиями. Да и в процессорах есть такие схемы экономии энергии, уж в Атоме точно есть.

Щас опять скажут, что я тролль. Не принижаю я разработчиков, на западе дураков ровно столько, сколько в любой стране. Можно подумать у них ракеты не взрывались из-за ошибки программистов(Ариан-2 кажется).

Я не представитель QNX. Что, собственно, как раз и написано.

Всё остальное я не будут комментировать, но float имеет размер 32 бит. Что, собственно, выдает непрофессионализм, согласно Вашим же утверждениям.

Конечно 32 бита. Но причём тут

непрофессионализм

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

Кстати, что в стандартах пишут про эти «лишние биты»? Небось как про memcpy, типа зависит от реализации. Там такого мусора в ANSI полно. То же «спецы» писали.

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

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

Уважаемый Mike Gorchak!
Извините, если Вам показалось, что я хотел принизить разработчиков.
Сначала немного практики про паранойю.

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

В первом случае программа под отладчиком работала, а на реальном железе глючила. Дело в том, что некоторые отладчики даже переменные в стеке обнуляют. А на реальном железе мусор вылез после того, как вместо штатной проги записали в контроллер тест, а потом опять в контроллер записали штатную программу. Мусор после теста попал туда, где был стек в штатной программе. Слава Богу, что это вылезло при испытаниях, а не в штатном режиме. Может другие операционки чистят память при старте, но наша не чистила для ускорения перезапуска. Это всё выяснилось при подстановке под отладчиком чисел из теста в область стека и получения идентичной лажи, как на объекте.

Во втором случае было обратное явление. На объекте программа работала до поры до времени, а под отладчиком дохла. Дело было так. Во время доработки давно отлаженной программы товарищ сделал небольшие корректировки, скомпилячил и без тестирования залил на объект и запустил, всё прошло как по-маслу, доложили о готовности и отправили железку на объект. Но тут заказчик проснулся и попросил ещё корректирнуть. Ну, другой товарищ попался более ответственным и запустил прогу под отладчиком, ну она и сдохла, ибо случилось деление на нолик (см. выше про отладчики, обнуляюшие стек).

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

Теперь о примере с float. Если дальше в стеке — буфер для пакета, куда вы эти float-ы пакуете:

float ff;

unsigned int buf[1000];

а Вася Пупкин написал далее удачный код с выходом за пределы массива, то в этом проклятом С++ никто не схватит за руку, когда индекс в массиве станет отрицательным или больше размера массива. Таким макаром местная программа легко упакует мусор в пакет, и прекрасно будет работать, пройдя все тесты. Ведь Вы в тесте будете проверять в буфере только те ячейки, в которые Вы в тесте положили свои красивые числа? А где-то далеко другая программа получит не-число NaN при распаковке массива обратно во float-ы.

Извините, если что, много букв получилось.

В данном примере вместо unsigned int нужно использовать uint32_t.

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

Про работу с неинициализированными переменными тоже существует пачка warning’ов.

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

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

индекс не расчитывается компилятором.

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

Конечно. Но только если индекс в массиве можно расчитать во время компиляции. А если это пременная, как можно её расчитать во время компиляции?

Давйте лучше про запись сборки.www.trtrussian.com/...68-451ee1c56d0bsat2.ru/...запуски/76.html

Не понятно как этот пример относится к 32-битной переменной передаваемой в 64-битном регистре.

Когда Вы пишете

float ff = f;хотя переменная 32 бита, команда ассемблера 64 битная, и ячейка памяти для переменной ff в стеке тоже 64 битная.

MSVC, например использует XMM регистры, где хранят по 4 float’а в 128-битовом регистре.

И какой в твоем случае сгенерился ассемблерный код?

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

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

Даёт, даёт. Из регистра переменная переписывается в стек с мусором (переменная ff). А дальше в стеке массив. Если в индексе массива поставить −1, попадаем на ячейку c мусором:
float funk(f) {
float ff = f;
unsigned int64 buf[100];
....
i = <вычисляем i, получаем −1>
при раcпаковке получаем
float fdura =
buf[i] >> 8;

и привет.

А когда переменная перед этим записывалась в регистр, мусор в верхнем/нижнем подрегистре не перезаписался? Это вообще реальная история или теоретизирование?

Когда Вы пишете f = 125.3456789 скорее всего старшие биты вытрутся. Но когда Вы принимаете пакет с упакованными данными, где у Вас и float-ы и куча всяких структур, немудрено Васе Пупкину наехать-переехать. Причем, если у Вас там уставки, которые реально при запуске оборудования равны нулю, то Вы пару лет ничего и не заметите. Когда заказчик поменяет уставки на ненулевые, он к Вам позвонит (если останется жив) и скажет: Ваша долбаная программа вылетела. Реальнее не бывает.

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

Фантазия — это хорошо. Вот когда её не хватает, тогда и усталось, и отсутствие понимания проблемы. Советую поспать

От недостатка фантазии бывает усталость? Логика зашкаливает. Иди проспись сам, а то в который раз бредятину писать начал.

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

Могу посоветовать лечится. У меня никакой усталости нету, я свеж и весел.

Я про это и говорю, свеж и весел бот, только демо-тива-тор поло-мался и устал

Линус не прав? Майк, давай поспорим. :)

www.developers.org.ua/...ums/topic/3692

Он не прав по умолчанию, потому что человек который выдает такое «I’m always right. This time I’m just even more right than usual. » не может быть прав по тому же умолчанию. Реально тяжелый человек в общении, мне двух раз хватило.

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

Обратная совместимость должна быть де факто, а не по докам, в которых написано «undefined», или «делайте как хотите».

Бред, в доках написано что нужно юзать memmove.

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

Что значит не определили? Определили.

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

И? В cygwin нету доки про memmove?

С детского сада люди знают, что memcpy — когда нет пересечений, memmove — когда они есть. Если кто плохо учился в детском саду — остальные тут точно ни при чем.

для заполнения — memset и т.п.

Рано или поздно жизнь расставляет все на свои места и бракоделы со своими багами вылазят на поверхность. В данном случае это — Adobe. Идти на поводу у криворуких халтурщиков — это очень очень накладное занятие.

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

Остальные возвращаются назад и подчищают за собой.

Кто учился плохо в детском саду, должен страдать больше, чем те, кто учились хорошо.

Ты прочитал сам-то то, что приводишь в пример? Черным по белому:

If the regions overlap, the behavior is undefined.

То есть, для тех кто в танке: использование для пересекающихся регионов — это 100% баг.

С детского сада люди знают, что memcpy — когда нет пересечений, memmove — когда они есть. Если кто плохо учился в детском саду — остальные тут точно ни при чем.

Что делать остальным платформам? И программным и аппаратным? Прогнуться под Линуса?

И баги фиксить не надо, ибо кто-то мог использовать его как фичу?

Возвращаясь к теме:

pubs.opengroup.org/...ons/memcpy.html

If copying takes place between objects that overlap, the behavior is undefined.

undefined — значит что никто ничего вам не обещал, и тот кто завязался га какое-то поведение должен или сам обеспечить это поведение или оперативно переписать под новое.

Обещал, должен... Детский сад какой-то

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

Суть в том что некий программист не удосужился прочитать спеку (или сознательно на нее поклал).

Вопрос в том:

Кто должен следить за изменениями платформа за сторонним софтом или разработчики стороннего софта за платформой которую они используют?

АПИ никто не ломал, насколько я понял, просто кто-то его неправильно использовал.

Простите, вы знаете что значит понятие «неопределенно»?

О каком ломании АПИ вы говорите, когда общаетесь на тему memcpy? АПИ этой функции постаршее линукса как такового и не менялась.

Мне Linux сугубо пофиг, мне важна кросс-платформенная совместимость. Я задал конкретный вопрос. Например, абсолютно реальный пример, QNX6 под SH процессоры, что делать там, чтобы работал адобовский плеер? Мне переписать memcpy()? Или всё-таки адобовский плеер пофиксить?

Тут скорее совет вам — не советуйте своими советами.

Я жду понимания, что Linux — это далеко не весь мир, вернее, даже не его малая часть. С этим нужно считаться.

Вот Ваша цитата, взята из субтреда ниже:

«Нельзя ломать существующий многолетний API. Нужно либо расширять API, либо делать чтобы новая версия не могла быть автоматически использована вместо старой.»

Есть The Open Group, за которой стоят сильнейшие IT корпорации мира, есть Linux, который спустя много лет всё так же далек от того, чтобы быть полностью POSIX-совместимой ОС во всех спецификациях. Подгонка функционирования POSIX API под существующие приложения — это заведомо ущербный путь, который отдаляет Linux от всего Unix-like семейства.

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

какое значение имеет флэш в интернет надеюсь объяснять не надо

Никакого, и с каждой секундой все меньше :)

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

Сейчас все побузят, кто включит у себя в дистрибутиве оптимизированную memcpy(), кто нет, но через несколько месяцев, пол года, как бы не кричали поборники подгонки API под приложения, им всем придётся пофиксить свои баги.

По мейл-листам я вижу, что многие уже тихо исправили свои ошибки ещё с лета 2010, не заливая гуаном форумы.

По поводу выгод, достаточно посмотреть на работу какой нибудь in-memory db, etc.

Підписатись на коментарі