Какова цель модификаторов h и hh для printf?

Одна из возможных причин: для симметрии с использованием этих модификаторов в функциях форматированного ввода? Я знаю, что это не было бы строго необходимым, но, может быть, в этом была ценность?

Хотя они не упоминают важность симметрии для модификаторов «h» и «hh» в документ с обоснованием C99, комитет действительно упоминает его как соображение о том, почему спецификатор преобразования "%p" поддерживается для fscanf() (хотя это не было новым для C99 - " %p" поддерживается в C90):

В C89 было добавлено преобразование входных указателей с помощью %p, хотя оно явно рискованное, для симметрии с fprintf.

В разделе, посвященном fprintf(), документ с обоснованием C99 действительно обсуждает добавление «hh», но просто отсылает читателя к разделу fscanf():

Модификаторы длины %hh и %ll были добавлены в C99 (см. §7.19.6.2).

Я знаю, что это тонкая нить, но я все равно размышляю, поэтому я решил привести любой аргумент, который может быть.

Кроме того, для полноты картины модификатор "h" был в исходном стандарте C89 - предположительно, он был бы там, даже если бы в нем не было строгой необходимости из-за широко распространенного использования, даже если бы не было технических требований к использованию модификатора. .

В режиме %...x все значения интерпретируются как беззнаковые. Поэтому отрицательные числа печатаются как их беззнаковые преобразования. В арифметике с дополнением до 2, которую использует большинство процессоров, нет разницы в битовых шаблонах между отрицательным числом со знаком и его положительным беззнаковым эквивалентом, который определяется арифметикой модуля (добавлением максимального значения для поля плюс один к отрицательному числу, согласно стандарту C99). Много программного обеспечения, особенно код отладки, который, скорее всего, использует %x, делает молчаливое предположение, что битовое представление знакового отрицательного значения и его беззнакового приведения одинаково, что верно только для машины с дополнением до 2.

Механика этого приведения такова, что шестнадцатеричные представления значения всегда подразумевают, возможно, неточно, что число было представлено в дополнении до 2, если оно не попадает в граничное условие, когда разные целочисленные представления имеют разные диапазоны. Это верно даже для арифметических представлений, где значение 0 не представлено двоичным шаблоном всех нулей.

Таким образом, отрицательный short, отображаемый как unsigned long в шестнадцатеричном формате, на любом компьютере будет дополнен f из-за неявного расширения знака в продвижении, которое будет напечатано printf. значение то же самое, но оно визуально вводит в заблуждение относительно размера поля, подразумевая значительный диапазон, которого просто нет.

%hx усекает отображаемое представление, чтобы избежать этого заполнения, точно так же, как вы пришли к выводу из вашего реального варианта использования.

Поведение printf не определено, когда передается int вне диапазона short, который должен быть напечатан как short, но самая простая реализация на сегодняшний день просто отбрасывает старший бит с помощью необработанного приведения вниз, поэтому, хотя спецификация не требует любое конкретное поведение, почти любая разумная реализация будет просто выполнять усечение. Однако, как правило, есть лучшие способы сделать это.

Если printf не заполняет значения или не отображает беззнаковые представления значений со знаком, %h не очень полезен.

Единственное, что я могу придумать, это передать unsigned short или unsigned char и использовать спецификатор преобразования %x. Вы не можете просто использовать голый %x - значение может быть повышено до int, а не unsigned int, и тогда у вас будет неопределенное поведение.

Ваши альтернативы: либо явно привести аргумент к unsigned; или использовать %hx / %hhx с голым аргументом.

Аргументы с переменным числом аргументов для printf() и др. автоматически повышаются с использованием преобразований по умолчанию, поэтому любые значения short или char повышаются до int при передаче в функцию.

В отсутствие модификаторов h или hh вам пришлось бы маскировать передаваемые значения, чтобы надежно получить правильное поведение. С модификаторами вам больше не нужно маскировать значения; реализация printf() делает свою работу правильно.

В частности, для формата %hx код внутри printf() может сделать что-то вроде:

va_list args;
va_start(args, format);

...

int i = va_arg(args, int);
unsigned short s = (unsigned short)i;
...print s correctly, as 4 hex digits maximum
...even on a machine with 64-bit `int`!

Я беспечно предполагаю, что short — это 16-битная величина; стандарт на самом деле не гарантирует этого, конечно.

Я нашел полезным избегать приведения при форматировании беззнаковых символов в шестнадцатеричный:

        sprintf_s(tmpBuf, 3, "%2.2hhx", *(CEKey + i));

Это незначительное удобство кодирования и выглядит чище, чем множественные приведения (IMO).

еще одно удобное место — проверка размера snprintf. gcc7 добавил проверку размера при использовании snprintf, так что это не удастся

char arr[4];
char x='r';
snprintf(arr,sizeof(arr),"%d",r);

поэтому это заставляет вас использовать больший символ при использовании% d при форматировании символа

вот коммит, который показывает эти исправления, вместо увеличения размера массива символов они изменили %d на %h. это также дает более точное описание

https://github.com/Mellanox/libvma/commit/b5cb1e34a04b40427d195b14763e462a0a705d23#diff-6258d0a11a435aa372068037fe161d24

Я согласен с вами, что это не является строго необходимым, и поэтому одна только эта причина не годится для библиотечной функции C :)

Это может быть «хорошо» для симметрии разных флагов, но в основном это контрпродуктивно, потому что скрывает правило «преобразования в int».