This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)
- From: Marek Polacek <polacek at redhat dot com>
- To: Martin Sebor <msebor at gmail dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Jason Merrill <jason at redhat dot com>, Nathan Sidwell <nathan at acm dot org>, Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 11 Dec 2018 13:15:23 -0500
- Subject: Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)
- References: <email@example.com> <20181211071726.GI12380@tucnak> <firstname.lastname@example.org>
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:
> 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."