From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49443 invoked by alias); 11 Dec 2018 18:15:43 -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 49200 invoked by uid 89); 11 Dec 2018 18:15:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=claim X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Dec 2018 18:15:26 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9943C308421A; Tue, 11 Dec 2018 18:15:25 +0000 (UTC) Received: from redhat.com (unknown [10.20.4.212]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CA80919C7D; Tue, 11 Dec 2018 18:15:24 +0000 (UTC) Date: Tue, 11 Dec 2018 18:15:00 -0000 From: Marek Polacek To: Martin Sebor Cc: Jakub Jelinek , "Joseph S. Myers" , Jason Merrill , Nathan Sidwell , Gcc Patch List Subject: Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363) Message-ID: <20181211181523.GT21364@redhat.com> References: <0f3f1395-adac-8b5f-82e4-e656bf1207fb@gmail.com> <20181211071726.GI12380@tucnak> <78a7396e-8a64-4919-82d6-38959fda0e55@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78a7396e-8a64-4919-82d6-38959fda0e55@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-SW-Source: 2018-12/txt/msg00728.txt.bz2 On Tue, Dec 11, 2018 at 09:59:27AM -0700, Martin Sebor wrote: > [*] The change in the patch is obvious enough to me. All it > does is accept more of the things that are accepted by GCC 8 > (enums, bools, wchar_t, etc.) and that inadvertently started > to be rejected as a result of my prior change. That the rules > can be made more restrictive is something different. Obvious changes should be obvious to anyone, not just the committer, IMHO. I don't think we should make the rules more restrictive; what we have in place seems to have worked fine and I would have thought it's clear that changing what the compiler accepts will never be an obvious change, unlike, say, fixing a test that fails with -m32 because it uses 'unsigned long' instead of size_t. > I recently brought up the question of the write w/o approval > policy on the gcc list: > > https://gcc.gnu.org/ml/gcc/2018-11/msg00165.html > > looking for clarification. Except for Jeff's comment (which > I'm afraid didn't really clarify things), didn't get any. > > You (the maintainers) have put it in place. If you don't intend > for the rest of us to make use of it, or if it's not meant to be > interpreted to give us the freedom to decide what is or isn't > obvious, then change it. But it's disingenuous to claim that "We > don't want to get overly restrictive about checkin policies" and > then chastise people each time they say they might check something > in on their own. ...or fixing typos in comments and formatting fixes should be obvious, adding new tests for fixed bugs likely as well, but outlining semantics in a comment doesn't strike me as obvious at all. "When in doubt, ask for a review." Marek