Sujet : Re: RP2350 and Pico 2 - things missing
De : invalid (at) *nospam* invalid.invalid (Richard Kettlewell)
Groupes : comp.sys.raspberry-piDate : 29. Aug 2024, 16:13:42
Autres entêtes
Organisation : terraraq NNTP server
Message-ID : <wwvwmjzs6op.fsf@LkoBDZeT.terraraq.uk>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
User-Agent : Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Ahem A Rivet's Shot <
steveo@eircom.net> writes:
Richard Kettlewell <invalid@invalid.invalid> wrote:
Ahem A Rivet's Shot <steveo@eircom.net> writes:
There are always the int<n>_t types for when size matters.
Life is not always that simple and declaring how things ‘should’ be
does not fix a single line of code.
>
Very true - horse, water, drink.
>
One of the public APIs we support largely uses ‘long’ and ‘unsigned
long’ for integral values, which causes occasional issues with our
cross-platform code. For example ‘unsigned long’ has the same size as
‘size_t’ on Linux, but not on 64-bit Windows.
>
Which is why putting assigning the value of a size_t to an unsigned
long or vice-versa is wrong.
No, it’s not necessarily wrong. If the value fits in the destination
type there’s nothing wrong with it. The results are well-defined and do
not change the value. You can look up the rules in the C standard.
The common case (for users of this API) is passing the size of a
relatively small object, of fixed size. There is no practical issue
there. The less common case is where the value is unknown at compile
time, meaning an extra check and an explicit conversion are needed. It’s
not remotely difficult to deal with, it’s just an annoyance (as I
previously wrote).
-- https://www.greenend.org.uk/rjk/