Почему существуют модификаторы длины hh и h в printf?

Рассмотрим этот пример:

#include <stdio.h>
int main(void)
{
    unsigned short x = 32770;
    printf("%d\n", x) ;  // (1)
    printf("%u\n", x) ;  // (2)
}

В типичной 16-разрядной реализации продвижение аргумента по умолчанию принимает значение от unsigned short до unsigned int, тогда как в типичной 32-разрядной реализации unsigned short становится int.

Таким образом, в 16-битной системе (1) является UB и (2) правильным, но в 32-битной системе (1) является правильным и (2) можно обсуждать, правильно ли это или UB.

Использование %hu для печати x работает во всех системах, и вам не нужно думать об этих проблемах.

Аналогичный пример можно построить для char в системах с sizeof(int) == 1.

Это для обратной совместимости.

В черновой версии стандарта C89 печать подписанного int , short или char со спецификатором %xformat не является неопределенным поведением:

d, i, o, u, x, X Аргумент int преобразуется в десятичное число со знаком ( d или i ), восьмеричное число без знака ( o ), десятичное число без знака ( u ) или шестнадцатеричное представление без знака ( x или X ); буквы abcdef используются для преобразования x, а буквы ABCDEF — для преобразования X. Точность определяет минимальное количество отображаемых цифр; если преобразуемое значение может быть представлено меньшим количеством цифр, оно будет дополнено начальными нулями. Точность по умолчанию равна 1. Результат преобразования нулевого значения с явно заданной нулевой точностью не содержит символов.

Похоже, это свидетельствует о том, что предварительно стандартизированный C с использованием спецификаторов формата, таких как %x для значений signed, был существующей практикой, поэтому, вероятно, существовала ранее существовавшая кодовая база с использованием модификаторов длины h и hh.

Без модификаторов длины h и hh значения signed char с битовым шаблоном 0xFF будут напечатаны в 32-битной системе int как 0xFFFFFFFF, если они будут напечатаны с помощью простого спецификатора формата %X.

Что касается конкретно спецификатора hh, он был явно добавлен в C99, чтобы использовать печать всех типов фиксированного размера по умолчанию из stdint.h/inttypes.h. C99 делает типы int_leastn_t от 8 до 64 обязательными, поэтому возникла необходимость в соответствующих спецификаторах формата.

Из обоснования C99 5.10, §7.19.6.1 (fprintf):

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

§7.19.6.2 (fscanf):

Новая функция C99: модификаторы длины hh и ll были добавлены в C99. ll поддерживает новый тип long long int. hh добавляет возможность обрабатывать символьные типы так же, как и все другие целочисленные типы; это может быть полезно при реализации макросов, таких как SCNd8 в <inttypes.h> (см. 7.18).

До C99 для печати целочисленных типов использовались только d, h и l. В C99 обычная реализация могла бы, например, определить спецификаторы inttypes.h как:

#define SCNi8   hh
#define SCNi16   h
#define SCNi32   d
#define SCNi64  ll

И теперь продвижение аргумента по умолчанию становится головной болью реализации printf/scanf, а не реализации inttypes.h.

Они предназначены не для printf() использования, а для scanf() возможности использовать ссылки на short целые числа и char целые числа. Для единообразия и полноты они принимаются для функций printf(), но они неразличимы, поскольку параметры vaarg функции printf() повышаются до int для всех параметров, которые имеют целочисленные значения типов short и char. Так что они эквивалентны в printf(), но не в scanf() и друзьях.