From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24805 invoked by alias); 12 Apr 2010 18:30:04 -0000 Received: (qmail 24747 invoked by uid 22791); 12 Apr 2010 18:30:02 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 12 Apr 2010 18:29:57 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 06BEE1B4031; Mon, 12 Apr 2010 18:29:55 +0000 (UTC) From: Mike Frysinger To: Joel Brobecker Subject: Re: [PATCH] sim: tweak signed to unsigned local vars Date: Mon, 12 Apr 2010 18:30:00 -0000 User-Agent: KMail/1.13.1 (Linux/2.6.33.2; KDE/4.4.1; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <1270936677-26654-1-git-send-email-vapier@gentoo.org> <201004121150.49169.vapier@gentoo.org> <20100412160618.GX19194@adacore.com> In-Reply-To: <20100412160618.GX19194@adacore.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3167244.pKJQ2TEgQ9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201004121429.11581.vapier@gentoo.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00379.txt.bz2 --nextPart3167244.pKJQ2TEgQ9 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-length: 1929 On Monday 12 April 2010 12:06:18 Joel Brobecker wrote: > > > I'm not sure I agree on this one. "tmp" is used to store the result of > > > a subtraction of 2 pointers. IIRC, the exact type returned is > > > ptrdiff_t, which is a signed value... > >=20 > > true, but the math should never yield a negative value. the compare is > > between a base pointer and a pointer returned from strchr() on the base > > pointer. so the value should always be >=3D 0 and it should always fit= in > > 32bits. >=20 > I always tend to be very careful with this type of reasoning, probably > because of my past writing safety-critical software (and also how > surprisingly difficult it turned out to be to formally prove that > a piece of code would never overflow). >=20 > Even if what you are saying is true, I think that we'll have less > conversion issues if we use the proper types. But that's just me. > Perhaps others with more C experience than I do will agree with you > that we're fussing over something that actually does not matter. this is a string passed via command line option. if it were even remotely= =20 close to the size required to overflow ("unsigned" -> "unsigned int" -> 32b= it=20 on all systems where this socket code is going to be used), something is=20 terribly wrong elsewhere. even if we grant it 16bit storage, a 65k string= =20 specifying a host:port makes no sense, especially when many systems have a= =20 hard time swallowing a command line over 32k. i dont have a problem coding defensively when it makes sense, but i cant se= e=20 any such requirements in any of the sim code. further, while ptrdiff_t may make sense since we're diffing two pointers, t= he=20 value is passed straight into strncpy() which interprets the value as size_= t.=20=20 so if we were going to spend the time on this (which i dont think this code= =20 warrants), a lot more code needs to change than the variable type. -mike --nextPart3167244.pKJQ2TEgQ9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAABAgAGBQJLw2Z3AAoJEEFjO5/oN/WB9rUP/RDkbQF1eEV0NDwMupofmUma N+mvRXSIRXv1nPePJUxoFQv05+eAP6qLl00ofht1xiX+sq3Wj1pr7O01I1r1X35o tn4x0zSHuQ7F0uY84Kmy6r0aTDWFa9+aNF0OLSB4yF/uJ+pnoXhlMwZ5fnv0hB+G rd3v3qM6ArEEnJvRieweG1bmKVWBM9C79z5KnH7WNlB5/vVbEIY0glSYsKSm9ESP ru5rkiA+qUkC2zz+oaEFs2qh3+AJ0Oveaa37Ui22r8SnB7HS3CeGww+O3o+hH0pv dWNJYATvCCsUAuuhsDzySbVf8y2edaz6Rud8hoBimqLqdpQLm3Et4dDov50vo5g8 GgaxlK8dmM2RgliV0lgKidcx5l7FbMgmpjHmCJqOqWSqZYNrUJBYvYXYK9RKWs32 s8Tw5y5iAukxxavXq9qWI/2SJUPw6yuUl48XGyUlK5xxlWQWQZuOCytpMac7361W 1AHgtPZp5VVuqT3CAP+tdiP8Jva5NK5VtaLpNE6DFIwjrhMdwpa/q8g6ornx6An7 Y1o2QA2dluLWDdf1J8Zxhc4pfRny5kL1vLohqIlZ90VeQDPle9KHOtHuCKIalRtw rtcko5A+DQSaC3kqwR6l2YdgwmDzL902Uq5ClK91wq9gUSXzLiBxlfK14ezTJmks niii0z0izV21a1EQ2tPu =NsVx -----END PGP SIGNATURE----- --nextPart3167244.pKJQ2TEgQ9--