Path: ...!eternal-september.org!feeder3.eternal-september.org!news.gegeweb.eu!gegeweb.org!nntp.terraraq.uk!.POSTED.tunnel.sfere.anjou.terraraq.org.uk!not-for-mail
From: Richard Kettlewell <invalid@invalid.invalid>
Newsgroups: comp.sys.raspberry-pi
Subject: Re: RP2350 and Pico 2 - things missing
Date: Thu, 29 Aug 2024 16:13:42 +0100
Organization: terraraq NNTP server
Message-ID: <wwvwmjzs6op.fsf@LkoBDZeT.terraraq.uk>
References: <v9lbfn$10qjj$2@dont-email.me> <v9pj3v$1qse0$7@dont-email.me>
	<lin8sjFbh5vU1@mid.individual.net> <va6s6f$c7dr$1@dont-email.me>
	<50ae75b3cdb83be61d995844169642d211670e3e.camel@munted.eu>
	<20240822115703.a377f409dd25c1b1f76f6c61@eircom.net>
	<va9k44$s0gf$2@dont-email.me>
	<20240823111241.fa25c2e204942a50ef8ccac5@eircom.net>
	<vac28j$1ab6s$6@dont-email.me>
	<20240824091356.eadff502925e2f0760693e89@eircom.net>
	<vagq3v$2a0g5$3@dont-email.me> <vai25u$2fn77$1@dont-email.me>
	<vajkr1$2rhoq$1@dont-email.me> <vajvlj$2shf7$1@dont-email.me>
	<valnib$35rt8$3@dont-email.me> <vao1af$3jojc$1@dont-email.me>
	<wwv4j73zq32.fsf@LkoBDZeT.terraraq.uk>
	<20240829102839.5bb67af25e568ebabc65ede6@eircom.net>
	<wwvle0febz4.fsf@LkoBDZeT.terraraq.uk>
	<20240829140519.0f9feb077b892bb9521f06c6@eircom.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: innmantic.terraraq.uk; posting-host="tunnel.sfere.anjou.terraraq.org.uk:172.17.207.6";
	logging-data="7559"; mail-complaints-to="usenet@innmantic.terraraq.uk"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Cancel-Lock: sha1:CM1Ck3nXNiiSDtA1RhA0qQpVj90=
X-Face: h[Hh-7npe<<b4/eW[]sat,I3O`t8A`(ej.H!F4\8|;ih)`7{@:A~/j1}gTt4e7-n*F?.Rl^
     F<\{jehn7.KrO{!7=:(@J~]<.[{>v9!1<qZY,{EJxg6?Er4Y7Ng2\Ft>Z&W?r\c.!4DXH5PWpga"ha
     +r0NzP?vnz:e/knOY)PI-
X-Boydie: NO
Bytes: 3277
Lines: 30

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/