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: Akshat Garg <xkspr7 at gmail dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Martin Sebor <msebor at gmail dot com>, gcc-patches at gcc dot gnu dot org, Paul McKenney <paulmckrcu at gmail dot com>, Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- Date: Fri, 30 Aug 2019 01:51:49 +0530
- Subject: Re: [PATCH] Adding _Dependent_ptr type qualifier in C part 1/3
- References: <CAMEQ7YzmTgrrtdqtr8e+Y8dCrXFamhX-U30sCkg921o0+KaSkw@mail.gmail.com> <email@example.com> <alpine.DEB.firstname.lastname@example.org>
Many thanks for giving us your feedback.
On Tue, Aug 20, 2019 at 3:57 AM Joseph Myers <email@example.com>
> 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
> > 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?
Can you help me in understanding why the _Atomic is excluded from the
standard references. I referred to the C standard draft N2310 (
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf) but I couldn't
understand how it is excluded? I want to know what properties should a
qualifier have to be in standard qualifiers list?
> 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