From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57760 invoked by alias); 20 Nov 2017 22:11:25 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 57742 invoked by uid 89); 20 Nov 2017 22:11:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-1.7 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=H*RU:sk:static., Hx-spam-relays-external:sk:static., H*r:sk:clients, =e5=b0=a7?= X-HELO: mail-wm0-f44.google.com Received: from mail-wm0-f44.google.com (HELO mail-wm0-f44.google.com) (74.125.82.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 Nov 2017 22:11:23 +0000 Received: by mail-wm0-f44.google.com with SMTP id 128so13159974wmo.3 for ; Mon, 20 Nov 2017 14:11:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=d+HnBE/pU824jlhrhSShthTHYCBAb1q8tNLhU0ANCjI=; b=bHZ2Vxqf1MpLXdgBQP6A4yVWdS0LCsWRWX8kiddtRKUsakGzGqQfdXYPA1DWHKA48J dr0oqbYNUYSrVsGZ/xn4/U5SHPRme0AJjs8B890NEY/Qy8kvGFyn2W1avcH8eAkejRgx VCvC9A0N8iLhy6hpXzvVSGle/y5K+fJMtP53voMOFtp6jw4Cwn1iESsELearItady4bX wF120n00e9BGFY5l9i274V0FlzJHMAY1pEWnLSGv6ri8BqP7YCr02Xc9L/4y486rDXVm 5PCisQB0BLnKkxDaRwtzjXNYD1BtRRFWdARx+qC+KxRByc0mIvk05I83rXpJOmhqx3NM yNUw== X-Gm-Message-State: AJaThX4dowWYv93TI/5z6V1dcggmDY9HRObyvF7cGxHO4QT8oXsRwWn7 aqZ5quIUlg3ZNmSl2hRyAeo= X-Google-Smtp-Source: AGs4zMYhOQFXd5OJEL/1sxz1pKW2fhKy08vLGLCuA8CUTaQ8diSj9nTq3C50ho8VcMjN3EbFLJ8tOQ== X-Received: by 10.28.17.77 with SMTP id 74mr10316517wmr.66.1511215880797; Mon, 20 Nov 2017 14:11:20 -0800 (PST) Received: from 1170ee0b50d5 (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id k5sm12510194wmg.21.2017.11.20.14.11.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 14:11:20 -0800 (PST) Date: Mon, 20 Nov 2017 22:11:00 -0000 From: Yao Qi To: Martin Sebor Cc: gcc@gcc.gnu.org, gdb@sourceware.org, msebor@redhat.com Subject: Re: Fail to compile GDB with recent GCC trunk (-Werror=stringop-overflow=, -Werror=stringop-truncation) Message-ID: <20171120221118.GF318@1170ee0b50d5> References: <86r2strlrd.fsf@gmail.com> <1a24cb6d-efa0-7f07-76cc-ca3708ee9d14@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1a24cb6d-efa0-7f07-76cc-ca3708ee9d14@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg00019.txt.bz2 On 17-11-20 09:33:46, Martin Sebor wrote: > On 11/20/2017 08:51 AM, Yao Qi wrote: > > > >Hi, > >I failed to compile GDB with GCC trunk (8.0.0 20171117) because of some > >-Werror=stringop-overflow= and -Werror=stringop-truncation warnings. > >Some of them are not necessary to me, > > I have the attached patch for two of these but I have been waiting > to submit it until the latest GCC patch has been approved that > adjusts the checker a bit. Hi Martin, can you post the patch to gdb-patches@sourceware.org? The patch can be reviewed there. > > > > >1. ../../binutils-gdb/gdb/python/py-gdb-readline.c:79:15: error: ‘char* strncpy(char*, const char*, size_t)’ output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation] > > strncpy (q, p, n); > > ~~~~~~~~^~~~~~~~~ > >../../binutils-gdb/gdb/python/py-gdb-readline.c:73:14: note: length computed here > > n = strlen (p); > > ~~~~~~~^~~ > > > >the code is simple, > > > > n = strlen (p); > > > > /* Copy the line to Python and return. */ > > q = (char *) PyMem_RawMalloc (n + 2); > > if (q != NULL) > > { > > strncpy (q, p, n); > > q[n] = '\n'; > > q[n + 1] = '\0'; > > } > > > >I don't see the point of warning here. > > The overall purpose of the warning is to help find likely misuses > of strncpy and strncat. As with any warning that's based on intent, > it cannot avoid highlighting some safe uses, or missing some unsafe > ones. As a user, false negative is fine to me, but false positive is too noisy. If I made stupid mistakes and compiler doesn't find them, that is fine. The people who wrote such bad code should be blamed, rather than compiler. However, if compiler emits many warnings to the correct code, it is annoying. Usually, "too many false warnings" == "no warnings". > > The case above is based on a heuristic designed to find bugs where > the bound depends on the length of the source rather the size of > the destination, as in: > > strncpy (d, s, strlen (s)); > > This is, unfortunately, a common misuse/mistake. It's often seen > in legacy code that's being updated in response to a security > mandate to replace strcpy with strncpy. > > The GDB use case, although safe, is also not how the function is > intended to be used. The intended use is to specify the size of > the destination, typically a statically allocated array, and have > the function fill it with data (not necessarily a string, and > not necessarily containing a terminating nul). When the array > is allocated dynamically and sized to store the entire string > it's preferable to use some other function (e.g., memcpy or > strcpy). The real issue here is GCC warning is too aggressive, and even emit warnings to the correct code. We fixed glibc, gdb, what is the next? GCC will be used to build thousands of packages, do you expect "fixing" all of them? If I have to fix my correct code, just because gcc complains about it, it is time I consider switching to other compilers to compile my code. > > > > >2. ../../binutils-gdb/gdb/cp-namespace.c:1071:11: error: ‘char* strncpy(char*, const char*, size_t)’ output truncated before terminating nul copying 2 bytes from a string of the same length [-Werror=stringop-truncation] > > strncpy (full_name + scope_length, "::", 2); > > ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > full_name = (char *) alloca (scope_length + 2 + strlen (name) + 1); > > strncpy (full_name, scope, scope_length); > > strncpy (full_name + scope_length, "::", 2); > > This is safe, although also not the intended use of the function. > The call above can be replaced either by memcpy or strcpy. There > also is no good way to avoid warning on it without compromising > the efficacy of the checker. > IMO, compiler != static analysis/checker, although they share many technologies. They have different responsibilities, compiler is to generate binary code from source code, while static analysis tool is to find problems in the code as many as possible. -- Yao (齐尧)