From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75629 invoked by alias); 1 Feb 2017 00:21:19 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 75586 invoked by uid 89); 1 Feb 2017 00:21:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=2980, 5220, literature, Formatting X-HELO: mail-qk0-f196.google.com Received: from mail-qk0-f196.google.com (HELO mail-qk0-f196.google.com) (209.85.220.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 Feb 2017 00:21:17 +0000 Received: by mail-qk0-f196.google.com with SMTP id i34so23640800qkh.3 for ; Tue, 31 Jan 2017 16:21:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KZHAvcDi16QSgNJcwEW9stZaDRRZw81xlTwSkENVuKY=; b=MhKZQwbl9MBmUCQeMNitH3mEJ337gU8H9au1lqQQaDM8AE1Tb5semqARWBZJ1R3xLI RFa7Bb/qe1r75F/4rCoI3WYDFrWTrx+Xwtr3C8FyS+pPBZq/186yuIaA5nzammeHX01V A4Rseprr/ROtkP8X0wfrxCroMDW8HWpmgcjG4se/eK8AO9hy04VR+Q9N5AIgyd24aVv6 R3wCboWfKW0rfckdtuBj1ftAsffr0tM8zEvgOiweHANjBzHXXW2CvmTdGec4y7EtvXUT O/7vr5TkDVtQckOHCNFzjbqvKs1cbW6QCNwIwjSwRTpipTPHivLPp5zGSaMNeGHaV+EY tVzA== X-Gm-Message-State: AIkVDXLw6eawxHtJ5G17/Bv9KOF4kQbj2uqx/BqSsr7ir400tshqzF78L4Y5Di3PuFz53Q== X-Received: by 10.55.153.130 with SMTP id b124mr86778qke.82.1485908475242; Tue, 31 Jan 2017 16:21:15 -0800 (PST) Received: from [192.168.0.3] (97-118-107-34.hlrn.qwest.net. [97.118.107.34]) by smtp.gmail.com with ESMTPSA id d15sm16847954qtg.22.2017.01.31.16.21.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2017 16:21:14 -0800 (PST) Subject: Re: [wwwdocs] changes.html - document new warning options To: Gerald Pfeifer References: <737b809f-d95a-8e68-4ac2-74600359afae@gmail.com> <28b0b2d5-4636-7465-5381-6c8750f5a6df@gmail.com> Cc: Aldy Hernandez , gcc-patches@gcc.gnu.org From: Martin Sebor Message-ID: Date: Wed, 01 Feb 2017 00:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00000.txt.bz2 On 01/31/2017 02:16 PM, Gerald Pfeifer wrote: > Wow, that's quite a patch. And quite some contributions behind that! :-) > > Let me offer some comments, and then I suggest you commit what you > have (taking these comments into account), and we can still improve > things then if there is further feedback. Sounds good. > > Index: gcc-7/changes.html > =================================================================== > +
  • GCC 7 can determine the return value or range of return values of > + some calls to the sprintf family of functions and make > + it available to other optimization passes. Some calls to the > + snprintf function with a zero size argument can be folded > > Formatting here appears a little odd? I wouldn't have that line break > afer . Sure. > > + into constants. The optimization is included in -O1 > + and can be selectively controlled by the > > "This optimization" Okay. > > +
  • GCC 7 contains a number of enhancements that help detect buffer overflow > + and other forms of invalid memory accesses. > > "buffer overflows" (plural) ? Both are common in literature. Google returns about 5,220 hits for the string "detect buffer overflow and" and about 2,980 for the singular, so I kept it as is. > > + errors. Such bugs have been known to be the source of > + vulnerabilities and a target of exploits. > > Perhaps say "security vulnerabilities"? Not sure about that. Sure. > + -Walloc-size-larger-than=PTRDIFF_MAX is included > + in -Wall.

    > > PTRDIFF_MAX without ... I would say, since it's not a variable. Okay. > > +

    For example, the following call to malloc incorrectly tries > > malloc Done. > > +void* f (int n) > +{ > + return malloc (n > 0 ? 0 : n); > +} > > Great example! :-) > > +

  • The -Walloc-zero option detects calls to standard > + and user-defined memory allocation functions decorated with attribute > + alloc_size with a zero argument. -Walloc-zero > + is not included in either -Wall or -Wextra > + and must be explicitly enabled.

    • > > Why are you adding

    within

  • ? This should not be necessary. Only for consistency with the other list items where it separates paragraphs (it made it easier for me to spot missing tags and such). I removed from where it was redundant. > > + sprintf is diagnosed because even though its > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Why ... here? It was a copy and paste typo. I removed the tags. > > + output has been constrained using the modulo operation it could > + result in as many as three bytes if mday were negative. > + The solution is to either allocate a larger buffer or make sure > + the argument is not negative, for example by changing mday's > + type to unsigned or by making the type of the second operand > + of the modulo expression to unsigned: 100U. > > "changing the type" > Right, thanks. > + -Wformat-overflow=1 is included in > > No ... around 1, since it's a constant (not a variable). Done. > > + nonnull). By taking advantage of optimization the option > + can detect many more cases of the problem than in prior GCC > + versions.

    • > > "optimizations" (Or "compiler optimizations", to avoid ambiguity > whether the option was optimized or is now leveraging compiler > optimizations?) > > +

  • The -Wstringop-overflow=type option detects > + buffer overflow in calls to string manipulation functions like > > "overflows" > > + memcpy and strcpy. The option relies > > Is memcpy really a string manipulation function? The C standard calls all the functions in (including memcpy) string handling functions. I'm not sure where I got "manipulation" from. I changed it to string handling though I'm not sure it's a big improvement given that memcpy arguments need not be strings. > > + on Object Size Checking and has an effect similar to defining > + the _FORTIFY_SOURCE macro. > > Naive question: What is "Object Size Checking", and where is it > introduced or desribed? It's described in the GCC manual. I added a link to it. > > + -Wstringop-overflow=1 is enabled by default.

    > > No s around constants. > > +

    For example, in the following snippet, because the call to > + strncat specifies a maximum that allows the function to > + write past the end of the destination, it is diagnosed. To correct > + the problem and avoid the overflow the function should be called > + with a size of at most sizeof d - strlen(d). > > I'm getting tired this evening, but is this taking care of the \0 > being added? Or would that require sizeof d - strlen(d) - 1? It sure would! I've committed the patch with the changes above (plus another example to make Aldy extra happy). Please let me know if you spot something else that needs adjusting. Thanks for the careful review (and debugging)! Martin