Jaki jest cel modyfikatorów h I hh Dla printf?

W trybie %...x wszystkie wartości są interpretowane jako niepodpisane. Liczby ujemne są zatem drukowane jako ich niepodpisane konwersje. W arytmetyce dopełniacza 2, używanej przez większość procesorów, nie ma różnicy we wzorcach bitowych między podpisaną liczbą ujemną a jej dodatnim, niepodpisanym odpowiednikiem, który jest zdefiniowany przez arytmetykę modułową (dodając maksymalną wartość dla pola plus jeden do liczby ujemnej, zgodnie ze standardem C99). Dużo oprogramowania - zwłaszcza kod debugowania najbardziej prawdopodobnie użycie %x - zakłada ciche założenie, że bitowa reprezentacja podpisanej wartości ujemnej i jej niepodpisanego rzutu jest taka sama, co jest prawdziwe tylko na maszynie dopełniacza 2.

Mechanika tego odlewu jest taka, że szesnastkowe reprezentacje wartości zawsze sugerują, być może niedokładnie, że liczba została wyrenderowana w dopełnieniu 2, o ile nie osiągnęła warunku krawędzi, gdzie różne reprezentacje liczb całkowitych mają różne zakresy. To nawet trzyma true dla reprezentacji arytmetycznych, gdzie wartość 0 nie jest reprezentowana wzorem binarnym wszystkich 0s.

Negatyw short wyświetlany jako unsigned long w hexidecimal będzie zatem na każdej maszynie wyściełany f, ze względu na niejawne rozszerzenie znaku w promocji, które printf wydrukuje. Wartość jest taka sama, ale jest wizualnie myląca co do wielkości pola, co oznacza znaczną ilość zakresu, który po prostu nie jest obecny.

%hx truncates wyświetlana reprezentacja, aby uniknąć tego wypełnienia, dokładnie tak, jak wywnioskowałeś z rzeczywistego przypadku użycia.

Zachowanie printf jest niezdefiniowane, gdy przekazywana jest int poza zakresem short, który powinien być wydrukowany jako short, ale najprostsza implementacja zdecydowanie odrzuca wysoki bit przez surowy downcast, więc podczas gdy specyfikacja nie wymaga żadnego konkretnego zachowania, prawie każda rozsądna implementacja po prostu wykona obcięcie. Generalnie są lepsze ale sposoby na to.

Jeśli printf nie jest wypełnianiem wartości lub wyświetla niepodpisane reprezentacje podpisanych wartości, %h nie jest zbyt użyteczne.

Jedyne zastosowanie, jakie przychodzi mi do głowy, to podanie unsigned short LUB unsigned char i użycie specyfikacji konwersji %x. Nie możesz po prostu użyć nagiego %x - wartość może być promowana do int, a nie unsigned int, a wtedy masz nieokreślone zachowanie.

Alternatywą jest albo jawne oddanie argumentu do unsigned; albo użycie %hx / %hhx z gołym argumentem.

Zmienne argumenty printf() et al są automatycznie promowane przy użyciu domyślnych konwersji, więc dowolne short lub char wartości są promowane do int po przekazaniu do funkcji.

W przypadku braku modyfikatorów h lub hh, należy zamaskować przekazane wartości, aby uzyskać prawidłowe zachowanie. Dzięki modyfikatorom nie trzeba już maskować wartości; implementacja printf() wykonuje zadanie prawidłowo.

W szczególności dla formatu %hx, kod wewnątrz printf() może zrobić coś takiego:

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`!

Zakładam, że short jest liczbą 16-bitową; standard tego oczywiście nie gwarantuje.

Uznałem, że przydatne jest unikanie rzucania podczas formatowania znaków niepodpisanych na hex:

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

Jest to niewielka wygoda kodowania i wygląda czystiej niż wiele odlewów (IMO).

Zgadzam się z Tobą, że nie jest to bezwzględnie konieczne, a więc tylko z tego powodu nie jest dobre w funkcji biblioteki C:)

Może to być" miłe "dla symetrii różnych flag, ale jest to w większości przeciwne do produktywności, ponieważ ukrywa regułę" konwersja do int".

Innym przydatnym miejscem jest sprawdzanie rozmiaru snprintf. gcc7 dodano sprawdzanie rozmiaru podczas korzystania z snprintf więc to się nie uda

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

Więc wymusza użycie większego znaku podczas używania %d podczas formatowania znaku

Oto commit, który pokazuje te poprawki zamiast zwiększania rozmiaru tablicy znaków, które zmienili %d na %h. to również daje dokładniejsze Opis

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