This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Adding _Dependent_ptr type qualifier in C part 1/3


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
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]