Почему следующий код вызывает ошибку сегментации?

Question

Почему следующий код вызывает ошибку сегментации?

0

Я пытаюсь выполнить команду UNIX через мою программу, которая будет обрабатывать до 4 аргументов, почему это либо приводит к ошибке seg, либо другим ошибкам?

using namespace std;

int main() {

char buffer[255];
cin >> buffer;


char* firstPtr;
char* secondPtr;
char* thirdPtr;
char* fourthPtr;

firstPtr = strtok(buffer, " ");
secondPtr = strtok(NULL, " ");
thirdPtr = strtok(NULL, " ");
fourthPtr = strtok(NULL, " ");


execlp(firstPtr, secondPtr);


   return 0;
}

Scholar 05 нояб. 2013, в 08:11

Источник

0

Потому что вы вызываете неопределенное поведение? (или ты уже знал это)? cin >> buffer разрывается на пробельных, так tokenizing это на " " спорно. поэтому secondPtr NULL, и вы счастливо secondPtr в UB-страну.
WhozCraig 05 нояб. 2013, в 06:32
0

"или другие ошибки?" Какие еще ошибки?
codeling 05 нояб. 2013, в 06:34
0

когда я выполняю ls ошибку, я получаю, что NULL передается в argv [0]
Scholar 05 нояб. 2013, в 06:37
0

Если вы не видите шаблон в коде ниже, std :: istream :: getline () .
WhozCraig 05 нояб. 2013, в 06:45

Показать ещё 2 комментария

Теги:

c++

unix

segmentation-fault

strtok

3 ответа

1

Если вы проверите man-страницу execlp, вы заметите, что первый аргумент (второй параметр для метода, параметр arg0) является обязательным, в дополнение к любым другим параметрам вы можете перейти к функции через переменные параметры - и это также упоминается в тексте, что

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

Первый аргумент (secondPtr в вашем случае) должен быть именем исполняемого файла; так что вы нарушаете соглашение, перейдя сюда в NULL (из-за cin >> другие уже указали).

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

Поэтому рекомендуется изучать страницы руководства!

codeling 05 нояб. 2013, в 04:41

1

Я думаю, вы должны использовать

char buffer[255];
cin.getline(buffer, 255);

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

lolando 05 нояб. 2013, в 04:04

Ещё вопросы

Потому что вы вызываете неопределенное поведение? (или ты уже знал это)? cin >> buffer разрывается на пробельных, так tokenizing это на " " спорно. поэтому secondPtr NULL, и вы счастливо secondPtr в UB-страну.
"или другие ошибки?" Какие еще ошибки?
когда я выполняю ls ошибку, я получаю, что NULL передается в argv [0]
Если вы не видите шаблон в коде ниже, std :: istream :: getline () .

Zaffy · Accepted Answer · 2013-11-05T05-28-00.000Z

2

Лучший ответ

Крушение происходит из-за buffer буфера.

Попробуйте использовать std::cin.getline(buffer, sizeof(buffer)) вместо std::cin >> buffer
Также обратите внимание, что strtok может возвращать NULL, поэтому убедитесь, что вы его обрабатываете.

Zaffy 05 нояб. 2013, в 05:28

0

Его буфер составляет 255 символов, и это приведет к ошибке ./prog ab .
WhozCraig 05 нояб. 2013, в 06:32
0

@WhozCraig Я попробовал это на моем компьютере, и сбой происходит только при переполнении буферов.
Zaffy 05 нояб. 2013, в 06:33
0

Спросите себя "Что имеет buffer , когда ввод вводится точно так же, как ab ?" Ответ на этот вопрос связан с этим вопросом: «Что вызывает извлечение строки из std::istream& to stop ? Среди прочего, пробел . Так что " b" все еще находится в потоке, а buffer содержит только "a" Теперь отправьте это в strtok() . Остальное, надеюсь, очевидно.
WhozCraig 05 нояб. 2013, в 06:37
0

@WhozCraig ./prog ab как вы ввели, a, b - аргументы, а не стандартный ввод, то есть он читает из
Zaffy 05 нояб. 2013, в 06:38
0

Ты абсолютно прав. ./prog , затем введите "a b" в ./prog строке. Спасибо, что поймали это. Тем не менее, переполнение буфера не требуется. (по иронии судьбы он мог просто запустить программу и ввести "./prog a b" в качестве подсказки для ввода, и та же проблема все еще возникла бы, в странной иронии судьбы).
WhozCraig 05 нояб. 2013, в 06:39

Показать ещё 3 комментария