Чи можуть компілятори та інтерпретатори мати помилки, і що ми можемо (як користувачі) зробити з ними? [зачинено]

Якщо робота компілятора по суті є перекладом вихідного коду в код машинного рівня, чи може бути якийсь збіг у компіляторі, тобто несправний "переклад?"

Те ж саме стосується і перекладача: чи не може він іноді виводити потрібний вміст?

Я не чув жодних помилок у компіляторах / перекладачах, але вони існують?

Так

Ви схильні знаходити їх більше в мовах, які активно розробляються, ніж в тих, які є відносно зрілими (і, отже, не спостерігають багато змін на частоті). Можливо, тому більшість мов випускається на різних "етапах" стабільності. Нічна збірка набагато рідше буде стабільною, ніж кандидат на реліз , який сам є меншим шансом бути стабільним, ніж повністю випущена та активно використовується версія.

На щастя, більшість із цих мов (особливо з відкритим кодом) матиме публічну систему відстеження помилок, до якої можна надсилати звіти.

На моєму власному досвіді я зіткнувся з досить незрозумілою, але сильною помилкою у Scala на Windows . Я подав свої висновки в програму пошуку помилок, і проблема була вирішена досить швидко. У цьому випадку розробники мови були досить розумні, щоб включити корисну примітку до виводу журналу помилок, підказавши, що те, що я зіткнувся, насправді була помилкою компілятора, і сказала, куди подати звіт.

Словами мирянина:

Усі програми можуть мати помилки.

Компілятори - це програми.

Так, компілятори можуть мати помилки.

Існують помилки навіть у апаратному забезпеченні; відомий приклад - помилка Pentium FDIV . Без сумніву, існує можливість, що компілятори містять помилки.

Компілятори та перекладачі теж є програмним забезпеченням, і тому вони не позбавлені жодної проблеми іншого програмного забезпечення.

Це приклад компілятора, недавно MSVC 11 (2012) , і ось стаття про те, як вони тестують бекенд .

Звичайно, тому що компілятори - це програмне забезпечення.

У 2005 році у мене виявилася помилка коду у дуже критичній програмі, яку я написав для великої компанії. Оскільки це коштувало компанії буквально мільйонів доларів для виправлення, вони, звичайно, розпочали велике розслідування.

На щастя (з моєї точки зору), ця проблема виявилася проблемою компілятора в Delphi. У блоці спробу нарешті повернене значення функції було знищено, і це призвело до абсолютно випадкових результатів назад до абонента. Це було задокументоване і визнане Борлендом.

У NET було відомо, що він має сотні сотень різних витоків пам'яті, особливо в ранній реалізації.

Я заперечую, що не існує такого поняття, як програмне забезпечення без проблем. Компілятори не є винятком. Вони проте протестовані більш ретельно, ніж більшість бізнес-програмних засобів, і їх споживають розумні, критичні та спорні люди, тому їх результати справді в цілому були досить хорошими.

Не лише помилки, а й навмисне зловмисне програмне забезпечення.

Найвідоміший із них - троян "входу", реалізований Брайаном Керніган для оригінального компілятора Unix C; стаття http://cm.bell-labs.com/who/ken/trust.html має деякі відомості щодо цього.

Так, звичайно, як і будь-які компілятори програмного забезпечення мають помилки, наприклад, список помилок gcc тут

Так.

Крім того, не тільки з компіляторами, але і з Інтерпретаторами / налагоджувачами та будь-яким стороннім програмним інструментом.

Наразі ми використовуємо програмне забезпечення сторонніх розробників, і виникли деякі проблеми. Іноді вони дякують нам за те, що знайшли та повідомили про помилку. :)

Деякі з них також мають деякі витоки пам'яті, що призводить до збоїв. Тут може бути важливим питанням, як визначити, чи сторонній інструмент чи компілятор мають помилки, щоб ваша програма працювала правильно?

Компілятор - це програма, яка читає програму, написану однією мовою (мова-джерело) і переводить її в іншу еквівалентну програму іншою мовою (цільовою мовою), переважно машинною мовою.

Існують різні фази компілятора, за допомогою яких ваш код вихідної мови сканується по черзі. Існує таблиця символів, яка відслідковує всі ключові слова, на які відскановано код коду мови.

Фаза 1: Лексичний аналізатор - читає всі символи у вихідній програмі та формує логічне розділення лексем (int, char, float, якщо інше, for, while тощо)

Фаза 2: Синтаксичний аналізатор - проаналізуйте структуру потоку лексем. Ієрархічний аналіз виразів, який включає постфікс / префікс тощо (a = b + c * d)

Фаза 3: Семантичний аналізатор - Введіть перевірку лексем (ціле число до реального, плаваюче тощо) та багато речей, таких як пріоритет оператора тощо.

Фаза 4: Генератор проміжного коду - a = b + c * de (temp1 = c * d, temp2 = temp1 + b, temp3 = temp2-e)

Фаза 5: Оптимізація коду - Різний аналіз (контрольний потік, потік даних, перетворення),
який виконує: Код надмірності, Подання констант, Частковий мертвий код, загальний підвираз, Код інваріантного циклу

Фаза 6: Створення коду - Створення цільового коду (здебільшого мови складання), що вводить значення в регістри

Усі ці етапи - це не що інше, як добре написані програми, і в цьому може бути N кількість недоліків.

Звичайно, компілятори - це просто програми, і їхні автори теж ідіоти :). Навіть специфікація мови може мати помилку. Приклад: c # + foreach + lambda .

Або в Python, помилка в інтерпретаторі: Компіляція злого астма дає збій інтерпретатору .

Ну, якщо ви хочете подивитися на помилки у компіляторі / інтерпетері -> подивіться на php. Є відомий помилка з цілим числом переповнення. Перше виправлення почалося з if (size > INT_MAX) return NULL;. Продовження історії .