Во-первых, приведите цитату, где я написал словосочетание "багованное API" - я жду. Не нужно присваивать мне то, что я не писал. Я написал, что проблема в ОС, в которой реализован искомый API.

Во-вторых - давайте. У Вас есть внешние переменные a и b. Внутри функция, принимающая эти переменные и осуществляющая операцию деления a на b. Если мы на входе присваиваем в b=0 то в результате у нас без обертки функция упадет с ошибкой.
Следовательно, игра вполне могла такую ситуацию воспроизвести, выдав на вход API не поддерживаемое значение или параметр, который не обязателен, можно вводить, можно не вводить, но его не протестировали, а до этого никто не пользовался.

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

это хардварные уязвимости при спекулятивном исполнении команд причем тут апи и вообще сони?

разве серии плейстейшен не больше 10 лет? или вы думаете они каждый раз все апи с нуля разрабатывали? апи это только команда зачем менять хорошо работающий список привычных команд для разработчиков?

вы написали свой пост после человека который писал про "багованное апи" я ошибочно посчитал это продолжением этой версии. моя ошибка.

это не проблема апи ведь так ошибка программиста создавшего программу?

Реализация, а не использование.

Команды, выполняются не на железе?

Архитектура поменялась.

Руль в машине крутится на 3 оборота. Вы ошиблись в подсчёте оборотов и попытались крутануть на 4-й.
4-й оборот не поддерживается. Руль отвалился, машина в кювете, вы в больнице.
Вопрос: то что руль отвалился проблема водителя т.к. он крутил руль больше чем положено или машины?

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

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


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

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

Если у машины есть недокументированная возможность(поворот руля на 4-й оборот отсоединяет руль), приводящая к катастрофическим последствиям, это проблема машины.

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

Какое-то кривое определение. Вот ИМХО лучше.
https://habr.com/ru/sandbox/52599/

читай на статью на хабре.

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

какие такие задачи выполняются "разными способами" и что не касается ядра ос и касается апи? вы пример можете хотяб привести? думаю что нет.

вот только фреймворк джаваскрипта (а именно такое раскрывается в статье) это не системное апи, а именно фреймворк и даже там есть глубокоговорящая мысль:


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

В реализации апи.

Могу.
Можно сделать игру. Графический движок будет работать через direct_x.
А можно сделать игру в excel (прецедент имеется). Я сильно сомневаюсь, что функции(с точки зрения игра API это функции экселя) экселя совпадают в direct_x.

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

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

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

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

Это использование.
Реализация это как команды, пришедшие через API выполняются.

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