Hi Joseph, Many thanks for giving us your feedback. On Tue, Aug 20, 2019 at 3:57 AM Joseph Myers <jos...@codesourcery.com> wrote:
> 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? > 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? Thanks, Akshat > > 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 > jos...@codesourcery.com >
