Re: [PATCH] tweaks: make three conversion specifications more compliant

[Hussam al-Homsi]

On 5/9/21, Benno Schulenberg <bensberg@telfort.nl> wrote:
> Op 09-05-2021 om 00:34 schreef Hussam al-Homsi:
>> https://man7.org/linux/man-pages/man7/system_data_types.7.html, which for
>> off_t says:
>>
>>         "Used for file sizes.  According to POSIX, this shall be a signed
>> integer
>> type."
>>
>> So the cast to intmax_t is fine as it matches the signedness, and then
>> "%jd"
>> matches the type.
>
> The cast to intmax_t may be fine, but why cast at all?

The actual type of off_t and the conversion specification used to
print it are unknown.
The combination could be int and "%d" on some platforms or long and
"%ld" on others, etc.
So we cast to a type that can hold off_t values and that we know how
to print: intmax_t and "%jd".
Without the cast the argument could be the incorrect type for the
conversion specification "%jd",
which is undefined behavior according to paragraph 9 on page 231 in
the PDF linked earlier.

>>         "Specifies that a following d, i, o, u, x, or X conversion
>> specifier
>> applies to a signed char or unsigned char argument"
>
> And how is that going to change anything?  A signed or unsigned char will be
> in the range 0x00 to 0xFF, that will fit perfectly fine in a %X.

It's about matching not fitting.
Now it doesn't change anything on my platform, but that doesn't
conclude that it's standard or portable.

GCC and Clang will silently compile the following original line in the patch:

        sprintf(hexadecimal, "U+%04X", (unsigned char)*this_position);

Change "%04X" to "%04lX" and only Clang will warn that the correct
format is "%04hhX" (as proposed in the patch).
I don't know why Clang doesn't suggest that for the original line.
It's a strange inconsistency.