Почему scanf возвращает неверное значение для переменной типа size_t?

Question

[evnuh]

Есть такой код:

const char* cookie_format = "uid=%zu-%s"; // sscanf into uid=size_t and hmac (in hex)

size_t uid;
char hmac[40];
auto scan_count = sscanf(cookie.c_str(), cookie_format, &uid, &hmac);

На входных данных:
uid=20364-726552704a0366dc3e0ca627e6ebacdeb8ecff70
получаем следующее:
uid=20224 hmac=726552704a0366dc3e0ca627e6ebacdeb8ecff70

Почему????

Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM 3.5.0)
Target: x86_64-pc-linux-gnu

Comments

[mamkaololosha]

Ты либо пиши на С, либо на С++03, либо на С++11. В каждом из стандартов задача решается.

Answer 1

[jcmvbkbc]

char hmac[40];
auto scan_count = sscanf(cookie.c_str(), cookie_format, &uid, &hmac);

На входных данных:
uid=20364-726552704a0366dc3e0ca627e6ebacdeb8ecff70
получаем следующее:
uid=20224 hmac=726552704a0366dc3e0ca627e6ebacdeb8ecff70

Потому что hmac[40], а должен быть hmac[41] судя по тому, что в строке 40 символов. Переполнение буфера, все дела. И %s лучше заменить на %40s

Comments

[evnuh]

Хорошо что есть умные люди) Спасибо!
Почему переполнение так странно сказывалось именно на uid? Он почему-то становился чуть меньше, чем распарсеный

[jcmvbkbc]

20364 == 0x4f8c
20224 == 0x4f00

Нуль-терминатор строки hmac перетёр первый байт uid, который оказался в памяти следом за hmac впритык к нему.

[evnuh]

значит я ошибался, когда отметал эту мыслю, т.к. думал что на стеке hmac после uid. А оно видать из-за того, чт остек растёт вниз и little endian, точно.

[jcmvbkbc]

На big endian был бы 0 с другой стороны, в твоём примере явно затирается наименее значащий байт.
Расположение переменных на стеке зависит от компилятора, но связано ли оно с направлением роста стека я хз.
Показал бы уж целиком функцию и её ассемблерный код.

[jcmvbkbc]

> Target: x86_64-pc-linux-gnu
какой нафиг big endian?

[evnuh]

jcmvbkbc: да я ужо исправил на little :)

Answer 2

[Кирилл]

Вы уверены что входные данные верны? Попробуйте передать просто строку. Такой код дает на выходе ровно то что ожидается: 20364-726552704a0366dc3e0ca627e6ebacdeb8ecff70

size_t uid;
char hmac[41] = "";
sscanf("uid=20364-726552704a0366dc3e0ca627e6ebacdeb8ecff70", "uid=%zu-%s", &uid, &hmac[0]);
printf("%zu-%s\n", uid, hmac);

Comments

[evnuh]

Уверен, у меня таких примеров - завались :) Проверял так:
std::cerr << cookie << " " << uid << " " << hmac << " !" << std::endl;

мне писали:

uid=106253-46b8941a2f7289fa964f5f82d792f53d98f543a7 106240 46b8941a2f7289fa964f5f82d792f53d98f543a7 !
uid=20364-726552704a0366dc3e0ca627e6ebacdeb8ecff70 20224 726552704a0366dc3e0ca627e6ebacdeb8ecff70 !

[evnuh]

Ещё чё забавно, если в куке нет подписи и дефиса, типа uid=106253 то всё верно возвращалось.

[Кирилл]

evnuh, а если считать uid не в size_t, а как строку например, он тоже не верный оказывается?

[evnuh]

Кирилл: нет всё ок
uid=117556-21d1055523d35aef205c4ec6e65e683fd228b16b 117556 21d1055523d35aef205c4ec6e65e683fd228b16b !