From patchwork Mon Dec 28 17:08:08 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Palka X-Patchwork-Id: 561334 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 1D9C4140C60 for ; Tue, 29 Dec 2015 04:08:43 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=cScYCHQb; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id; q=dns; s=default; b=nv7re2M/f/Cl DekaIrV4WuiK4xnxae9g0niSy6fGtiCKxuY9uJasozsuf+GMwcW20U6pPL16TgSj 6yKwUkjb5VHGigX4AFvuWQAFvMNw2hIB3m7m1qrmF+Xm5dus3ImhMcZ5hyZeDFkd iXZ4wHq+ekGBckwrqrPfvEzTbRrslyg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id; s=default; bh=LvAMZo+33tI3rdU00x Y67yWrgGY=; b=cScYCHQbe0/abN3gSOWzFpKInIlJolonIefi8Z7IVSzNoDG9Va +nsWMJRILKhgoF1S3dwWmVIp93cT6alMHzTT3lTOuMnStqBwCQYFhi3yPArBbSCX 7ufDLFlM7Npknrwoeie9pn2UD7jhVdX3p3LslGGxgt1qBOy0cX6NtwLmU= Received: (qmail 116662 invoked by alias); 28 Dec 2015 17:08:24 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 116536 invoked by uid 89); 28 Dec 2015 17:08:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=3314, H*Ad:U*palves X-HELO: mail-qk0-f169.google.com Received: from mail-qk0-f169.google.com (HELO mail-qk0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 28 Dec 2015 17:08:20 +0000 Received: by mail-qk0-f169.google.com with SMTP id k189so197147193qkc.0 for ; Mon, 28 Dec 2015 09:08:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=ZayyuI3bDgHlyUoG01Poh2FZG/IiZUPSephhVTxO7PY=; b=D219FlK1fySMMXm8InNLwgeOGI6MkfsKWiVrz/zbie37dNZscYrzUgZaQi1FqcX155 M80VijPi3KFnELX+PXG2ZdgF9Q+2DeRAU9DJn8XouoC8zojKPfSLcxms+mO3Q5hPwX5B nwU31Xq2C4GjGhPAVMFJ8IvQvJie3jjgM1NZyV1K0XFTlSWoOZwi+97h6PbyYpRtVN3w KPVYZqhD5He6+TMEDGiAdNl2zllLYPWxyPAAdAr9ciZxIB8y4otRkw80zaZlJE4+/PTl MhhnBsMbpVZtIPpxrE1QqathVKZ8NfiulGiqUN3PW0Qf/O4Fkhhiq9uiRxr4ms0JbjCD M2+g== X-Gm-Message-State: ALoCoQnCn35tqfTAhl3c5lJpg4+WmsUnn0ZoOQsCuY8piJZU8fI0i1Kc0FLxsUOG5lxR2WQPAos04pCQRoMMB4NPUrI5Qcstzg== X-Received: by 10.55.75.203 with SMTP id y194mr49058117qka.2.1451322498264; Mon, 28 Dec 2015 09:08:18 -0800 (PST) Received: from localhost.localdomain (ool-4353a8be.dyn.optonline.net. [67.83.168.190]) by smtp.gmail.com with ESMTPSA id f132sm9526399qhe.6.2015.12.28.09.08.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 28 Dec 2015 09:08:17 -0800 (PST) From: Patrick Palka To: gcc-patches@gcc.gnu.org Cc: dj@redhat.com, ian@airs.com, palves@redhat.com, Patrick Palka Subject: [PATCH] [libiberty] Tweak the documentation of libiberty's xcrc32 function Date: Mon, 28 Dec 2015 12:08:08 -0500 Message-Id: <1451322488-1087-1-git-send-email-patrick@parcs.ath.cx> In some places the xcrc32 documentation refers to GDB's own crc32 implementation, but GDB no longer has its own crc32 implementation. It now uses libiberty's xcrc32 throughout. So this patch removes these references to GDB's now-nonexistent crc32 implementation. Also, there appears to be a bug in the table-generation program embedded within the documentation. When the variable "int i" is >= 128, the computation "i << 24" shifts a one bit into the sign bit (assuming a 32-bit int), which is UB. To avoid this UB, I think it is sufficient to make the induction variables i and j have type unsigned int. This bug seems latent, however. I ran the program before and after this change and the table output is the same. libiberty/ChangeLog: * crc32.c: In the documentation, don't refer to GDB's now-nonexistent crc32 implementation. In the table-generation program embedded within the documentation, change the type of the induction variables i and j from int to unsigned int, to avoid UB. --- libiberty/crc32.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/libiberty/crc32.c b/libiberty/crc32.c index 12d9be0..52c982f 100644 --- a/libiberty/crc32.c +++ b/libiberty/crc32.c @@ -33,15 +33,14 @@ #include "libiberty.h" -/* This table was generated by the following program. This matches - what gdb does. +/* This table was generated by the following program. #include int main () { - int i, j; + unsigned int i, j; unsigned int c; int table[256]; @@ -146,10 +145,9 @@ starting value is @var{init}; this may be used to compute the CRC of data split across multiple buffers by passing the return value of each call as the @var{init} parameter of the next. -This is intended to match the CRC used by the @command{gdb} remote -protocol for the @samp{qCRC} command. In order to get the same -results as gdb for a block of data, you must pass the first CRC -parameter as @code{0xffffffff}. +This is used by the @command{gdb} remote protocol for the @samp{qCRC} +command. In order to get the same results as gdb for a block of data, +you must pass the first CRC parameter as @code{0xffffffff}. This CRC can be specified as: