From: already5chosen@yahoo.com
On Sun, 11 Jan 2026 11:51:43 -0800
Tim Rentsch 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), 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.
>
> It seems unlikely that any implementation would make such a
> choice. Can you name one that does?
Four out of four target for which I write C programs for living in this
decade:
- Altera Nios2 (nios2-elf-gcc)
- Arm Cortex-M bare metal (arm-none-eabi-gcc)
- Win32-i386, various compilers
- Win64-Amd64,various compilers
Well, if I would be pedantic, then in this decade I also wrote several
programs for Arm32 Linux, where I don't know whether uint32_t is alias
of 'unsigned int' or 'unsigned long', few programs for AMD64 Linux,
where I know that uint32_t is an alias of 'unsigned long' and may be one
program for ARM64 Linux that is the same as AMD64 Linux.
But all those outliers together constitute a tiny fraction of the code
that I wrote recently.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
