Позволяет нам рассмотреть следующую программу:
#include <stdlib.h>
int main(int argc, char **argv){
int a,b;
if (argc != 3)
return -1;
a = atoi(argv[1]);
b = atoi(argv[2]);
a = b ? a/b : 0;
return a;
}
Задача состоит в сбое программы, предоставляя аргументы в командной строке.
Передайте a как платформу INT_MIN и b как -1. Затем вы получаете ошибку переполнения на любой машине с двумя дополнениями, хотя это не обязательно сбой.
Ответ на этот вопрос: это зависит.
Одна из критических частей информации, которую вам нужно знать, - это способ реализации atoi и соответствия стандартам. В стандарте очень мало сказано о деталях реализации и более конкретно о поведении входных выходных данных. Предположим, что на минуту он действительно соответствует стандартам и сосредоточен на реализации.
Существует несколько методов, которые могут быть справедливо использованы, и один из них рекурсивно. Предположим на секунду, что он реализован как главный рекурсивный алгоритм, который заставляет наращивать стек. Я мог бы заставить эту программу сбой, предоставив достаточно длинный аргумент, который заставил atoi записаться достаточно глубоко, чтобы переполнение стека и, следовательно, сбой приложения.
Вы можете работать назад через процесс устранения:
1) Можете ли вы получить деление на ноль? Скорее всего, не. Если b равно 0, последнее выражение равно 0, и если оно не равно 0, вы не получите деления на ноль.
2) Можете ли вы предоставить неправильное количество аргументов и сбой при доступе к массиву? На самом деле не из-за более ранней проверки argc
3) Если ваши аргументы не переводятся на число, atoi должен возвращать числовое значение. Я думаю, что это часть спецификации библиотеки и, следовательно, не открыта для изменения реализации, но я могу ошибаться.
Итак, я не вижу, как вы могли бы свалиться здесь.
Единственное, что мне нравится в этом вопросе, - это деление на нулевую часть - он проверяет, что вы понимаете оператор?: и 0 является ложным. Мне не нравится эта часть, не давая вам доступ к справочному руководству. Я должен был проверить документы, чтобы быть уверенным.
Потенциал переполнения/переполнения слишком сложный ИМХО. Это здорово, если вы проводите собеседование для инженера по безопасности программного обеспечения, но я бы не стал спрашивать кандидата на начальном уровне или даже просто для стандартного задания на программирование. Если вы пришли с других языков (например, Python), это особенно сложно.
Обновление: я сделал онлайн-поиск по нескольким ссылкам, и кажется, что atoi должен возвращать 0 на плохой ввод. Например, из MSDN:
Каждая функция возвращает значение int производится путем интерпретации ввода символы как число. Возврат значение равно 0 для atoi и _wtoi, если ввод не может быть преобразован в значение этого типа.
Единственная возможная слабость, которую я вижу, - atoi(). Возможно, если бы она была передана достаточно большой струны, она бы неправильно вступила в нее. Помимо этого, деление на 0 покрывается как счетчик аргументов. Единственное, что я могу придумать, - это как-то переполнение буферов операционных систем путем спама мусора в аргументы. Не слишком вероятно.
Я не знаю, как большинство ОС передают данные argv. Является ли он выделен в стеке? Является ли он ограниченным по длине?
Не могли бы вы передать очень длинный параметр командной строки и создать переполнение стека?