From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31640 invoked by alias); 1 Aug 2005 12:33:38 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 31617 invoked by uid 22791); 1 Aug 2005 12:33:34 -0000 Received: from kitt.34sp.com (HELO kitt.34sp.com) (217.163.9.141) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 01 Aug 2005 12:33:34 +0000 Received: (qmail 46720 invoked from network); 1 Aug 2005 12:33:31 -0000 Received: from localhost.34sp.com (HELO localhost) (127.0.0.1) by localhost.34sp.com with SMTP; 1 Aug 2005 12:33:31 -0000 Received: from 62.253.198.200 ([62.253.198.200]) by webmail.vw1600e.org.uk (IMP) with HTTP for ; Mon, 1 Aug 2005 13:33:31 +0100 Message-ID: <1122899611.42ee169b74f47@webmail.vw1600e.org.uk> Date: Mon, 01 Aug 2005 12:33:00 -0000 From: Matthew Jones To: gcc-help@gcc.gnu.org Cc: Constantin@vw1600e.org.uk, Greubel@vw1600e.org.uk Subject: RE: bit shifting doesn't work as expected MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-SW-Source: 2005-08/txt/msg00010.txt.bz2 > I have the following small programm, and I don't understand why the > number is feeded with ones from the right, but not with > zeros. To elaborate a bit on the other response : this is usually called "sign extended shift right". It preserves the sign of a signed integer, which is stored in the top bit (0 = +ve, 1 = -ve). If you have 2 signed integers, a, and b, such that a = -b, then shift them both x bits right, then it will still be true that a = -b. If the sign bit is not preserved, -ve numbers change into very large +ve numbers after a shift right. For example, for 16 bit signed integers: non sign extended: 11000000 (-64) >>2 ==> 00110000 (48) sign extended: 11000000 (-64) >>2 ==> 11110000 (-16) The first one is correct if the numbers are UNSIGNED, and the first represents +192 rather than -64. > And the next question would be: How can I manage it to get zeros, > instead of ones? As suggested, use unsigned data types. HTH -- Matthew JONES http://www.tandbergtv.com/