This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Adding _Dependent_ptr type qualifier in C part 1/3
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Martin Sebor <msebor at gmail dot com>
- Cc: Akshat Garg <xkspr7 at gmail dot com>, <gcc-patches at gcc dot gnu dot org>, <paulmckrcu at gmail dot com>, Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- Date: Mon, 19 Aug 2019 22:27:46 +0000
- Subject: Re: [PATCH] Adding _Dependent_ptr type qualifier in C part 1/3
- Ironport-sdr: +XgScIOrkOsVHJ/teBrOrbNHyZjRs+6N7Ta4XT5BJweaEGAFcjHreEuZMLEHAskowCF5+fYDw1 X3k07C9N2rot7DdAdK4SXKKOjIo1wKTVuKPjpp8EuaFH0vhZWgijCo4fGWvgorH5DjHILHUtas qoCzQ4Y2G/snNgOH42YdKnXOZihRFPt6XDRzGsK/PBLTmXQXczsGLtoS9rqI+sC+qL/7bNJThG gvx2qdHgd5kj7ufv093NdpkeaFmUxKWJpFWuia0dN8QD4thZELm6egFOJgX20gZJpnQIxYLrEj epo=
- Ironport-sdr: 9nFZmUJ2/64Zioi484e/i9oSf4iCefT4fhk30NSsQPc2tUT4dMF3w+JAbOKGupQfzsGIRAJqXA 8Ig3Xg0g2/f/VX781DAAYpT5BxYBGn1Ltj4Bf5BqT4ele8hSGXbfAnD25mUzZ5pFFwi2qQGtIc quTNoRS3XI3UNNdFphAqjHB5XNtZbSviUdmeaN/KoVDHVZ8DaxfNNnlM5TiBUARdduorBQh39w s6hNKt3YIgF6F2K6YSBR/TcF98nXeJkCl1FIsZtE2Ck6zxiW9ZwoAPkVP/dwiACDKIGIAb8ZDJ hwA=
- References: <CAMEQ7YzmTgrrtdqtr8e+Y8dCrXFamhX-U30sCkg921o0+KaSkw@mail.gmail.com> <firstname.lastname@example.org>
On Tue, 30 Jul 2019, Martin Sebor wrote:
> On 7/30/19 1:13 AM, Akshat Garg wrote:
> > Hi,
> > This patch includes C front-end code for a type qualifier _Dependent_ptr.
> Just some very high-level comments/questions. I only followed
> the _Dependent_ptr discussion from a distance and I'm likely
> missing some context so the first thing I looked for in this
> patch is documentation of the new qualifier. Unless it's
The first question for any new thing that is syntactically a qualifier is:
is it intended generally to be counted as a qualifier where the standard
refers to qualified type, the unqualified version of a type, etc.? Or is
it, like _Atomic, a qualifier only syntactically and generally excluded
from references to qualifiers?
For the _Atomic implementation I had to go through all the references to
qualifiers or TYPE_MAIN_VARIANT in the front end and consider in each case
whether it handled _Atomic correctly, given that _Atomic is not counted as
a qualifier in the standard (so the unqualified version of const _Atomic
int is _Atomic int not int, and so can't be derived simply by using
TYPE_MAIN_VARIANT, for example). Some cases didn't need changing because
the handling (e.g. diagnostic for different types) was still appropriate
for _Atomic even though not formally a qualifier, but plenty did need
changing and associated tests added.
Such a check of front end code is probably unavoidable (before a change is
ready for trunk, not necessarily for an initial rough RFC patch) for any
new qualifier, whether it counts as a qualifier in standard terms or not
(and the patch reviewer will need to do their own check of references to
qualifiers or TYPE_MAIN_VARIANT that didn't get changed by the patch), but
the answer to that question helps indicate whether the default is to
expect code to need changing for the new qualifier or not.
> you point to it? (In that case, or if a proposal is planned,
> the feature should probably either only be available with
> -std=c2x and -std=gnu2x or a pedantic warning should be issued
There should not be any -std=c2x (flag_isoc2x) conditionals simply based
on "a proposal is planned". flag_isoc2x conditionals (pedwarn_c11 calls,
etc.) should be for cases where a feature is *accepted and committed into
the C2x branch of Jens's git repository for the C standard*, not for
something that might be proposed, or is proposed, but doesn't yet have
specific text integrated into the text of the standard.
If something is simply proposed *and we've concluded it's a good feature
to have as an extension in any case* then you have a normal
pedwarn-if-pedantic (no condition on standard version) as for any GNU
extension (and flag_isoc2x conditions / changes to use pedwarn_c11 instead
can be added later if the extension is added to the standard).
Joseph S. Myers