From: david.brown@hesbynett.no
On 11/01/2026 14:32, Michael S wrote:
> On Sun, 11 Jan 2026 04:59:47 -0800
> Keith Thompson wrote:
>
>> Michael S writes:
>>> 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),
>>
>> I'm sure. uint32_t is an alias for some predefined integer type.
>>
>> This:
>> uint32_t n = 42;
>> printf("%u\n", n);
>> has undefined behavior *unless* uint32_t happens to an alias for
>> unsigned int in the current implementation -- not just any 32-bit
>> unsigned integer type, only unsigned int.
>>
>> If uint32_t is an alias for unsigned long (which implies that
>> unsigned long is exactly 32 bits), then the call's behavior is
>> undefined. (It might happen to "work".)
>>
>
> What exactly, assuming that conditions (a) and (b) fulfilled, should
> implementation do to prevent it from working?
> I mean short of completely crazy things that will make maintainer
> immediately fired?
If an architecture has 32-bit "unsigned long", then "unsigned int" is
necessarily also 32-bit (since "unsigned int" is always at least 32-bit,
and "unsigned long" cannot be smaller than "unsigned int"). The very
fact that you listed "unsigned int is at least 32-bit wide" as an
assumption shows you are not well versed with the basics of C standards
in this area.
I agree that it is difficult to imagine an implementation where
"uint32_t" is "unsigned long" and where the code example you gave would
not work as expected. But there are countless cases where C programmers
have thought "it doesn't matter if this is UB, the compiler can't
generate code other than the way I think it should". Could some future
implementation on some future architecture do something I don't expect
with the code example here? I am not willing to bet against that
possibility - certainly not for something as petty as skipping a single
letter in the source code.
But to my mind, the prime disadvantage of writing this incorrect code
(besides portability, which is not always a big concern) is that you
block important and useful automated checks. That's just bad
development practice. Don't worry about compiler maintainers getting
fired for doing crazy things - worry about C programmers getting fired
for doing crazy things. (I wouldn't immediately fire someone for
writing code like this, but I'd reject it in a code review, and I'd have
serious concerns about a programmer who knowingly wrote UB without
vastly better justification than you have.)
>
>> If uint32_t and unsigned long have different sizes, it still might
>> happen happen to "work", depending on calling conventions. Passing a
>> 32-bit argument and telling printf to expect a 64-bit value clearly
>> has undefined behavior, but perhaps both happen to be passed in 64-bit
>> registers, for example.
>>
>
> And that is sort of intimate knowledge of the ABI that I don't want to
> exploit, as already mentioned in my other post in this sub-thread.
Writing code that is UB but "works as intended" /does/ require an and
rely upon an intimate knowledge of the ABI. You are saying this works
precisely because you know things about the ABI you are using. Writing
correct code will keep it portable and working regardless of the ABI.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
