Неправильные спецификаторы формата в scanf (или) printf

Что касается функции printf, я понимаю следующее из нескольких ссылок и экспериментов.

  • Когда мы пытаемся напечатать целочисленное значение с помощью спецификаторов формата, которые используются для float (или) double , и наоборот, поведение непредсказуемо .
  • Но можно использовать %c для печати символьного эквивалента целочисленного значения. Также допустимо использование %d для вывода значения ASCII (целочисленных представлений) символа.

Аналогичным образом, каково поведение scanf, если имеется несоответствие спецификатора формата и аргументы переданы в scanf . Стандарты определяют это?

4 голоса | спросил Vivek Maran 11 +04002012-10-11T03:33:50+04:00312012bEurope/MoscowThu, 11 Oct 2012 03:33:50 +0400 2012, 03:33:50

1 ответ


0

Аргументы Variadic (те, которые соответствуют многоточию, ...) продвигаются по умолчанию . Это означает, что все более короткие целочисленные типы переводятся в int (или, в зависимости от ситуации, без знака). Нет разницы между целыми числами и символами ( я полагаю ). Разница между %d и %c в ---- +: = 4 =: + ---- - это просто способ отформатировать .

printf - это другой котелок с рыбой. Все передаваемые аргументы являются указателями . Среди указателей нет продвижения по умолчанию, и очень важно, чтобы вы передали точный спецификатор формата, соответствующий типу указателя.

В любом случае, если ваш спецификатор формата не соответствует предоставленному аргументу (например, передача scanf в int * в %p), результат не определен поведение , что гораздо хуже, чем быть «непредсказуемым» - это означает, что ваша программа просто плохо сформирована.

ответил Kerrek SB 11 +04002012-10-11T03:40:53+04:00312012bEurope/MoscowThu, 11 Oct 2012 03:40:53 +0400 2012, 03:40:53

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132