From: jameskuyper@alumni.caltech.edu

On 2026-01-11 06:20, Michael S wrote:
> On Sat, 10 Jan 2026 22:02:03 -0500
> "James Russell Kuyper Jr."  wrote:
>
>> On 2026-01-09 07:18, Michael S wrote:
>>> On Thu, 8 Jan 2026 19:31:13 -0500
>>> "James Russell Kuyper Jr."  wrote:
>> ...
>>>> I'd have no problem with your approach if you hadn't falsely
>>>> claimed that "It is correct on all platforms".
>>>
>>> Which I didn't.
>>
>> On 2026-01-07 19:38, Michael S wrote:
>> ...
>> > No, it is correct on all implementation.
>>
>
> The quote is taken out of context.
> The context was that on platforms that have properties (a) and (b) (see
> below) printing variables declared as uint32_t via %u is probably UB
> according to the Standard (I don't know for sure, however it is
> probable), but it can't cause troubles with production C compiler. Or
> with any C compiler that is made in intention of being used rather than
> crafted to prove theoretical points.
> Properties are:
> a) uint32_t aliased to 'unsigned long'
> b) 'unsigned int' is at least 32-bit wide.
>
> I never claimed that it is good idea on targets with 'unsigned int'
> that is narrower.

I've looked for a previous restriction of this discussion to cases
covered by a) and b) above. The closest I could find is the following:

> In the case I am talking about n declared as uint32_t.
> uint32_t is an alias of 'unsigned long' on 32-bit embedded targets, on
> 32-bit Linux, on 32-bit Windows and on 64-bit Windows. It is
> alias of 'unsigned int' on 64-bit Linux.

Note several points: that is a period after the first use of "uint32_t",
so "the case" you're specifying ends there. I read the next three lines
as information about your working environment, not restrictions on the
claimed validity of your preference for "%u" over "%lu". There is no
mention of a restriction on the size of "unsigned int".

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)