From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 27 Jun 2016 14:19:59 +0800 From: Antonio Quartulli Message-ID: <20160627061959.GB10666@prodigo> References: <20160612041426.26339-1-a@unstable.cc> <1613308.eWzkVEsf7s@bentobox> <20160627023613.GX10666@prodigo> <2649945.JKXkXjyaxK@sven-edge> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zb2WCku5UPqpvxO1" Content-Disposition: inline In-Reply-To: <2649945.JKXkXjyaxK@sven-edge> Subject: Re: [B.A.T.M.A.N.] [PATCH v5 3/4] batman-adv: B.A.T.M.A.N. V - implement GW selection logic List-Id: The list for a Better Approach To Mobile Ad-hoc Networking List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sven Eckelmann Cc: b.a.t.m.a.n@lists.open-mesh.org --zb2WCku5UPqpvxO1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 27, 2016 at 08:19:22AM +0200, Sven Eckelmann wrote: > On Monday 27 June 2016 10:36:13 Antonio Quartulli wrote: > > On Mon, Jun 13, 2016 at 01:26:31PM +0200, Sven Eckelmann wrote: > > > On Sunday 12 June 2016 12:14:25 Antonio Quartulli wrote: > > > > + if (orig_throughput < (gw_throughput + threshold)) > > > > + goto out; > > >=20 > > > Possible overflow problem in batadv_v_gw_is_eligible. We don't > > > know what the user will add here and what the gw_throughput is. > > >=20 > > > We already had a similar problem in the BATMAN_IV gw selection > > > code which resulted in weird gw selections. See f63c54bba31d > > > ("batman-adv: Avoid u32 overflow during gateway select"). > >=20 > > Sven, correct me if I am wrong, but in f63c54bba31d we are changing the= type of > > the variables aimed to contain the value computed by the "overflowing" > > operation, while in this case we have everything in a if condition: sho= uld the > > temporary result be implicitly casted to a larger variable as required ? >=20 > No, it isn't casted to a larger type. Yes, C has some wild casting rules = but I > would not be aware of an "help the programmer to avoid overflows" casting > rule. >=20 > We had no other idea how to fix it in the mentioned commit. But here we c= an do > it without casting to u64. ok, thanks ! I will modify the patch in the next series. Cheers, --=20 Antonio Quartulli --zb2WCku5UPqpvxO1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXcMWPAAoJEJ4aZjxxc6bKhjsP/j2fylKbfuquL1DLiTlfjRPs Xw1fMvew/vYPWxwvaoecCLT34iXjXgAyCT8pbJ1UgLnSPveRFKVOy5/7xxRPozlu /32tgA+rdXTNbtEj0X0E48D4U0qTVYMwFISOKHA9kYFs0nc47CYDE6u5HGkxGxwT VsvH/tuSV0vtvZcx/e3yi5+FFivZN9U+Yp5h3MBI58WVUSNF/L+/XutL57TVUzyd NDW0VMT2c4nbyTtzpsXDQsQmfKPIKGP8B1JIO4iAGyFOpJU7EahozF5t8RZG8QlV h+uWbgrZCqrnGkKdl2UOBwo8EuQfnnUCy1StYxxkNjgYzArAEa1ErDVse4jb32AS pMCMHGg5qEBfzGJJZYJva5Bi2Um028H3OaziH/R3wfFmiD2R4kXfbtPYTd733X0N MoWtkXTxhlIOLoPwGqKRh/uIqsOy0CtfM3iFocI/XWwfhQeyM3V447KqrrMJxI77 N/fxBo1MSEYCuJtBup7kQISXlycTs4eEQWE2rTkbUZhcBj9o1QPMtuaWAsE5ixB3 qcGFz7Bdv9xSFz1/m9wT4bsYzP91RmUz9a3AGCKwElyKBFN8nay/hw7WmvISfZ+c 1trrho6Mr0XwNNeWmUN4QbPb/J8U4NS+aQOD47ssGBtwahk3rFBMo1LnFn6nJ80R Ig7Xr0Y894k9yMktXHQF =iODe -----END PGP SIGNATURE----- --zb2WCku5UPqpvxO1--