From owner-freebsd-current Sat Dec 14 5:12:50 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2851F37B401; Sat, 14 Dec 2002 05:12:47 -0800 (PST) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id A453D43ED4; Sat, 14 Dec 2002 05:12:22 -0800 (PST) (envelope-from ru@whale.sunbay.crimea.ua) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) by whale.sunbay.crimea.ua (8.12.6/8.12.6/Sunbay) with ESMTP id gBEDBklx012784 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 14 Dec 2002 15:11:46 +0200 (EET) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.6/8.12.6/Submit) id gBEDBfSB012774; Sat, 14 Dec 2002 15:11:41 +0200 (EET) Date: Sat, 14 Dec 2002 15:11:41 +0200 From: Ruslan Ermilov To: Bruce Evans Cc: "Andrey A. Chernov" , bwk@bell-labs.com, obrien@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: New AWK bug with collating Message-ID: <20021214131141.GD6946@sunbay.com> References: <20021213150942.GE86638@sunbay.com> <20021214202522.L5768-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ChQOR20MqfxkMJg9" Content-Disposition: inline In-Reply-To: <20021214202522.L5768-100000@gamplex.bde.org> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --ChQOR20MqfxkMJg9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 14, 2002 at 09:02:40PM +1100, Bruce Evans wrote: > On Fri, 13 Dec 2002, Ruslan Ermilov wrote: >=20 > > On Fri, Dec 13, 2002 at 04:41:06PM +0300, Andrey A. Chernov wrote: > > > On Fri, Dec 13, 2002 at 14:32:40 +0200, Ruslan Ermilov wrote: > > > > Pardon my ignorance here, but the following fragment > > > > returns -1, doesn't it? > > > > > > > > #include > > > > void > > > > main(void) > > > > { > > > > int i; > > > > > > > > i =3D (unsigned char)1 - (unsigned char)2; > > > > printf("%d\n", i); > > > > } > > > > > > It very depends on compiler, i.e. does it implements "value preseving= " or > > > "unsigned preserving" for 'char' type conversions. Or ANSI C vs. comm= on C > > > mode. Better be safe for both. > > > > > > Read 6.10.1.1 section here: > > > http://wwwrsphysse.anu.edu.au/doc/DUhelp/AQTLTBTE/DOCU_067.HTM >=20 > For ANSI C, the result of the subtraction only depends on the width > of unsigned char. If unsigned char has the same width as int, then > the result is UINT_MAX; otherwise the result is -1. This is an example > of the brokenness of "value preserving" conversions -- the value is > as far as possible from being preserved. >=20 > Then assignment to "int i" may cause overflow. There is no overflow if > the RHS is -1. If the RHS is UINT_MAX, then the result of the assignment > is implementation-defined. The value is is preserved even less than befo= re. > I think it is usually -0 on 1's complement machines. >=20 > So ache's changes is basically a fix for 1's complement machines. I don't > see much point in it, sincw we assume 2's complement in most places in > libc/string (except strcoll() :-). E.g., memcmp() just subtracts the > unsigned char's and assume that all the conversions turn out like they > do on 2's complement machines. We actually use an assembler version of > memcmp on most arches but... >=20 Hmm, then how you could explain the difference between -traditional and -ansi outputs for the following fragment on i386: int printf(char *, ...); int main(void) { long long l; unsigned char c1 =3D 1; unsigned char c2 =3D 2; l =3D c1 - c2; printf("%lld\n", l); l =3D -1; printf("%lld\n", l); } Or the same code but with `long' on sparc64. > > This is handled by the -traditional flag of gcc(1): > > > > : `-traditional' > > : > > : Attempt to support some aspects of traditional C compilers. > > : Specifically: > > : > > [...] > > : > > : * Integer types `unsigned short' and `unsigned char' promote = to > > : `unsigned int'. > > > > With -traditional, the code I quoted still produces -1. >=20 > It produces overflow which normally gives -1 on 2's complement machines. >=20 > > In any case, this section doesn't apply to this case because > > no conversion described in section 6.10 is ever done here, > > since both operands are of the same type, "unsigned char". >=20 > Yes it does. The common type (for arithmetic operators like subtraction) > is never smaller than int. Both of the unsigned char operands get > converted to int in the simplest case where unsigned char is smaller > than int. See 6.10.1 (5) and 6.10.1.1 about "integral promotions". >=20 I stand corrected, thanks for explanations, now I see they do. Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --ChQOR20MqfxkMJg9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE9+y4NUkv4P6juNwoRAj38AJwLluEEfaMKFQ05PDnLUDc/eb128QCfT+Af YOmsw1Bp2azHhmbzOl2l9Oc= =irfa -----END PGP SIGNATURE----- --ChQOR20MqfxkMJg9-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message