From: jameskuyper@alumni.caltech.edu
On 2026-01-14 04:10, Michael S wrote:
> On Tue, 13 Jan 2026 22:17:09 -0500
> "James Russell Kuyper Jr." wrote:
>
>> 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".
>>
>>
>
> Ignoring for a minute that what I claimed about 32-bit Linux is
> at best non-universal and at worst universally wrong, how would you
> formulate what I meant?
> My knowledge of English punctuation rules is rather minimal and even
> less than that for its US American variant.
I'm not sure exactly what you intended. And, as I mentioned in another
sub-thread, I've worked for most of my career under rules that
prohibited me from writing code that depends upon the kinds of details
that you're talking about - as a result, I've had little reason to
familiarize myself with those details. However, I can say that using
"%u" to print a value of unsigned long type has no chance of working
unless unsigned int and unsigned long have the same size and
representation. Even if they do, the behavior is still undefined, but
there's a pretty good chance it will work.
How could it fail? As an extension, an implementation could define an
ABI for use with variadic functions that adds a tag to each value
indicating its type, and could add a feature to to access
those tags. The printf() and scanf() families of functions could use
that feature to check for compatibility between the type specified by
the forma specifier, and the actual type of the corresponding argument.
Upon finding a mismatch, it could issue run-time diagnostic or even
abort your program. Such an implementation would be allowed by the fact
the behavior of your program is undefined when there is such a mismatch.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
