From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wMeHOHUUgGETbwAAWB0awg (envelope-from ) for ; Mon, 01 Nov 2021 12:23:17 -0400 Received: by simark.ca (Postfix, from userid 112) id D4D251F0BB; Mon, 1 Nov 2021 12:23:17 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 344B91EE14 for ; Mon, 1 Nov 2021 12:23:17 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8DC653858029 for ; Mon, 1 Nov 2021 16:23:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8DC653858029 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1635783796; bh=ch68fEltjpWMefbPJGBz6Z2SHQ23BjTJOs94R62Twcc=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=yLMadFDIww76KirxP0+IOmo5lFC7KsOPlqREE8RmMFX6zCH6aae8mWc6ti6OOVLrv dgqU+a6r+a8qdYq+k44BjrwPV4i9i2ULpiCijIVauYYrDs9LuubWAtwTNO3CYSx5AY aGE3gZ4dD+huQOHWsXbt98rkVHuOSjJJN/pVm+5Q= 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 To: Christian Biesinger 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-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: , From: Mike Frysinger via Gdb-patches Reply-To: Mike Frysinger Cc: gdb-patches Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" --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--