From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 379763858432 for ; Mon, 1 Nov 2021 16:22:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 379763858432 Received: by smtp.gentoo.org (Postfix, from userid 559) id 87AD2342D61; Mon, 1 Nov 2021 16:22:56 +0000 (UTC) Date: Mon, 1 Nov 2021 12:22:58 -0400 From: Mike Frysinger To: Christian Biesinger Cc: gdb-patches Subject: Re: [PATCH] sim: mn10300: clean up pointer casts Message-ID: Mail-Followup-To: Christian Biesinger , gdb-patches References: <20211101034519.29154-1-vapier@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ieKXEoTbmk0ABYKg" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2021 16:22:59 -0000 --ieKXEoTbmk0ABYKg Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 01 Nov 2021 12:07, Christian Biesinger wrote: > On Sun, Oct 31, 2021 at 11:45 PM Mike Frysinger via Gdb-patches > wrote: > > --- a/sim/mn10300/dv-mn103ser.c > > +++ b/sim/mn10300/dv-mn103ser.c > > @@ -238,7 +238,7 @@ do_polling_event (struct hw *me, > > { > > SIM_DESC sd =3D hw_system (me); > > struct mn103ser *serial =3D hw_data(me); > > - long serial_reg =3D (long) data; > > + long serial_reg =3D (uintptr_t) data; >=20 > Shouldn't you change the variable type too? the types are already confused, but long here is fine as any other. uintpt= r_t is not really any more correct. serial_reg comes in as an unsigned_word via the memory read/write callbacks, (encoded) cast to void*, and (decoded) cast to long. the memory read/write callbacks verify the values are always with= in the serial_register_types enum range which looks like [0,16] range, so any = of these types work. > Otherwise this patch seems to be somewhat pointless? > if ( nr_bytes =3D=3D 1 ) i don't know which one you mean, or why you think any of them are pointless. the nr_bytes checks are in the read/write code paths of the memory mapped register callbacks. so nr_bytes is needed & correct there. the uintptr_t casts happen when passing information to the scheduled callba= ck which is after the nr_bytes checks. i'm not anti trying to clean up these device models, i just don't have any personal interest in them, so i'm not inclined to spend time on them anymore than compiler warnings/failures force me to, or to make progress in unifying all the ports. the lack of test coverage also makes me a bit inclined to n= ot get too invasive if i can avoid it. -mike --ieKXEoTbmk0ABYKg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmGAFGIACgkQQWM7n+g3 9YHf5Q//RmG8IuYEVQfSepDShEPKVohRUHXEqLVdK2kVdEBCPZxas0jC10PjJJ0h 3p5kSGQPmlCNMA4VX8jS5ZLovWIDitiQvAwiVoA/pQy658JPHbYIB6+Nrlmglez0 q6yNyh+KGb/yFaEMZJwTJ37sbnohbOjOV+bfq5dqFgShce/6pigOd3W22ME5UE+n Pn2n2qeAFMmV5Fd8+WLr04LdJWc7VgZecAKQXwrOAbLfc/HF29PUmd/Y7jTdrCWQ qZkaGRMj03YDXUozh6ieVg0YYXhlN7qYdISJPYyI5pel8ProQ7i9D8mmEdeGX16I HaZzh9hI2zi4ENudEnRqDrc2A7IsJ5x+4EEVKYD6xIc3ZZYc/4XCBhRN3LkrpVt+ NgWINbR8Y8EzI89mqge8GK+PczEtEUzJQq6d+C/VD7QLX5LMrO434Az5PmlgL/SX HBg6ouAi8HK0lvAIBiAdlSaiMkZsi63h0z3PWfqKwHBccWcRETy4/Kl7I3sSN4Iq 8+ByFTODqv0wJb8Orm+09mJEazhz6KBqjm95EC2OK85oCZpS2sI8yicz205M719r ticfI+lCw9xQRoxDY3TF0lTT8W314RAL7nlySRPWqrGThI8vdZiaAycqndueWa3B apjXO59zAABSaAT6npUGcGckhXVpQ4H/4f6F9HSYd8siv7GPCns= =yTYY -----END PGP SIGNATURE----- --ieKXEoTbmk0ABYKg--