From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.wavenetuk.net (unknown [195.26.37.10]) by sourceware.org (Postfix) with ESMTP id DFE0F386F42F for ; Tue, 1 Dec 2020 21:08:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DFE0F386F42F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=iain@sandoe.co.uk Received: from [192.168.1.212] (host81-138-1-83.in-addr.btopenworld.com [81.138.1.83]) by smtp2.wavenetuk.net (Postfix) with ESMTPA id B89AB6000C6; Tue, 1 Dec 2020 21:08:08 +0000 (GMT) Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH v2] C-family : Add attribute 'unavailable'. From: Iain Sandoe In-Reply-To: Date: Tue, 1 Dec 2020 21:07:51 +0000 Cc: Joseph Myers , GCC Patches Content-Transfer-Encoding: 8bit Message-Id: <58DA3359-110D-457F-A1C5-B48E1D15DF25@sandoe.co.uk> References: <1DC1B5BE-1FCE-4E55-9F91-96A475D0CA84@sandoe.co.uk> <7f03ea0f-df1e-2520-f831-ebe20f5d4797@gmail.com> To: Martin Sebor X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, KAM_COUK, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_SHORT, KHOP_HELO_FCRDNS, MAY_BE_FORGED, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2020 21:08:12 -0000 Hi Martin, Martin Sebor wrote: > On 11/29/20 6:56 PM, Iain Sandoe wrote: >> Martin Sebor via Gcc-patches wrote: >>> On 11/10/20 12:38 PM, Iain Sandoe wrote: >>>> —— commit message. >>>> If an interface is marked 'deprecated' then, presumably, at some point >>>> it >>>> will be withdrawn and no longer available. The 'unavailable' attribute >>>> makes it possible to mark up interfaces to indicate this status. >>> Making an interface unavailable isn't the intent of deprecation in >>> standards like C, C++, or POSIX. Rather, the intended next stage >>> after deprecation is to make the interface available for other uses, >>> either by the standards themselves, or by implementations, or by >>> programs (if its name is not in the reserved namespace). So unless >>> you have other kinds of deprecation in mind this doesn't seem like >>> a fitting use case. >> coming at things from the standards perspective .. perhaps. >> .. however, in the first set of cases above, one never needs to indicate >> unavailability since the entity never becomes unavailable, it changes >> meaning. >> In practice, we don’t have markup of keywords etc. to indicate this (such >> deprecation has been handled specifically in the FEs). >> The practical (and actual) use of these attributes is in describing the >> lifecycle >> of system APIs. >> In that context, one could see it being used to describe APIs withdrawn >> in, say, >> a Posix standard (as implemented by a given system or according to >> specific >> compile-time flags). > > Just for the sake of clarity, to make sure we are both talking about > the same thing, the term POSIX uses for "withdrawn" when referring > to APIs is removed. Withdrawn is a term that ISO tends to apply to > whole standards. For example, ISO 9945:2003 AKA SUSv3 is a withdrawn > revision of POSIX (likewise, C99 and C11 are withdrawn revisions of > C). > > With that, the APIs that have been removed in recent POSIX versions > would not be appropriately described by the attribute, either on > paper, in the POSIX spec (if the hypothetical case when the attribute > was specified the C standard), or in implementations. The APIs simply > don't exist and so are open to use by programs (unless they are in > the reserved namespace), or by implementations as extensions. > The latter typically means that the APIs are defined (i.e., can > continue to be linked to by legacy applications) but not declared > in the system's header so they can be defined by programs. Declaring > removed APIs with the unavailable attribute would prevent that and so > would not be conforming. > > An example from C (not yet POSIX) is the gets() function that was > removed in C11 (it's still SUSv4). It's only declared in > when targeting older versions of C and C++. Because in more recent > versions of the standards gets is not a reserved name it's valid > for programs to declare symbols named gets (of any kind). So > declaring gets in with attribute unavailable would be > nonconforming. > > My point here is not necessarily to object to the idea behind > the attribute but to draw attention to the fact that it's not > suitable for standard APIs. I understand (and have no disagreement with) that this is not a facility that could be used as an enforcement of standard’s compliance. ==== However, imagine that you are a system integrator, and you have a system which supports the API of SUSv3 and some of the additions of later systems; let’s say you want to help your users avoid use of APIs which would be unavailable on a SUSv3 system You could mark up your implementation’s headers such that when presented with some compile flags, it made the toolchain emit an error if the user attempted to use APIs that are not present in SUSv3. This is not actually a completely inane goal - despite that SUSv3 is retired - in reality (AFAICS) there is only one system that’s qualified to UNIX7. >>>> It is used >>>> quite extensively in some codebases where a single set of headers can >>>> be used >>>> to permit code generation for multiple system versions. >>> >>> This sounds like a different use case than the next stage after >>> deprecation. I haven't come across it but I imagine its purpose >>> is to foster portability between variants or flavors (rather >>> than versions) of APSs? Say one set of APIs for a feature-rich >>> desktop variant of an OS versus a subset of the same APIs for >>> an embedded, more limited variant of the same OS. >> In the case of Darwin, the compilers are capable of targeting multiple >> versions >> of the system (one doesn’t need a separate GCC or clang to target each >> version, >> there is a -mmacosx-version-min= flag that allows the target version to >> be specified >> on the command line). >> Rather than install many versions of headers (and libraries) for all the >> system >> versions, the designers elected to have one copy with markup that >> describes the >> availability of APIs. >> the lifecycle is typically: >> introduced from version P.Q (ergo, unavailable before that) >> perhaps deprecated at version R.S (ergo the user should be warned) >> withdrawn at version X.Y (and unavailable thereafter). >> The headers contain macros that are expanded according to the version >> for which the code is being compiled - to produce deprecation warnings or >> unavailability errors if such APIs are *used* in the code. > > I see. That seems like a Darwin-specific use case, or one that may > be suitable for proprietary APIs not covered by the three language > standards (C, C++, or POSIX) where the attribute could only be used > this way as a non-conforming extension. I suppose it might also be > applicable in the case of Linux distributions whose vendors support > multiple versions simultaneously, although I haven't come across > this use case. Well, I resisted the ‘easy way out’ [which would be to make this a target-only attribute] since it does appear to me to be useful in a wider context. Absent facilites are never used, of course. >>>> From a configuration perspective, it also allows a compile test to >>>> determine >>>> that an interface is missing - rather than requiring a link test. >>>> The implementation follows the pattern of attribute deprecated, but >>>> produces >>>> an error (where deprecation produces a warning). >>>> This attribute has been implemented in clang for some years. >>> >>> The Clang manual says the attribute is useful in conjunction with >>> the enable_if and overloadble attributes in C, to remove overloads >>> of C functions from the overload set. I'm trying to think how >>> the GCC implementation of the attribute might be useful in >>> the subset of cases that don't depend on the other two attributes >>> but I'm coming up empty (exceot for the different variants of >>> an API use case that seems rather esoteric). It seems to me >>> the use case is close to #pragma GCC poison except more nunanced >>> (i.e., it doesn't poison a name but its uses in the given namespace, >>> as in functions, types, members, etc.) >> Hopefully, the description above clarifies the intent. >> It is possible, even likely, that the implementations in clang have >> additional >> capabilities above those implemented in this first cut - and perhaps we >> might >> adopt some of those in follow-on work. >> however the immediate use-case is the hundreds of instances where APIs >> are marked up in the manner I’ve outlined above. >>>> +@cindex @code{unavailable} function attribute >>>> +The @code{deprecated} attribute results in an error if the function >>> ^^^^^^^^^^ >>> >>> This should presumably read unavailable. >> yes, good catch >>>> +It is expected that items marked as @code{deprecated} will eventually >>>> be >>>> +withdrawn from interfaces, and then become unavailable. This attribute >>>> +allows for marking them appropriately. >>> >>> In Clang, declaring a member unavailable doesn't have the same effect >>> as withdrawing it (which I would interpret as removing). The member >>> still takes up space, so if this patch does the same I think this >>> effect should be made clear here. >> The intent is to match the behaviour of clang sufficiently closely that >> GCC can >> make more effective use of the system headers on Darwin platforms (and, of >> course, allow for the same kind of life cycle markup on other platforms). >>> Like attribute deprecated, I suspect attribute unavailable in GCC >>> will also be subject to the same catch 22 of marking up both a type >>> and its uses in APIs. E.g., in: >>> >>> struct __attribute__ ((deprecated)) A { ... }; >>> >>> struct B { >>> // Clang accepts this w/o warning, GCC warns. >>> struct A a __attribute__ ((deprecated)); >>> int i; >>> }; >>> >>> With unavailable, the problem will be made worse due to the error. >> so this is a bug in GCC’s availability attributes (not specifically >> caused by >> this patch) - addressing it for deprecation would naturally carry over >> to the >> unavailable case. >>> To be generally usable, I think GCC needs to change to behave more >>> like Clang. As a motivating example, consider the deprecated POSIX >>> getitimer API: >>> >>> struct itimerval { int it_interval, it_value; }; >>> int getitimer (int, struct itimerval*); >>> int setitimer (int, const struct itimerval*, struct itimerval*); >>> >>> All three names are deprecated and so using each one alone outside >>> the header that declares them should trigger a deprecation message; >>> the declarations themselves must not. If/when the APIs are removed, >>> marking them unavailable in the headers must likewise not trigger >>> errors. >> Is there a PR for this ? >> (IMO it’s still a separate issue, curing the problem for deprecation >> will also >> cure it for unavailability). > > There are a number of bugs for attribute deprecated. The one that's > probably the closest to this problem is: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754 > > It's been open since 2014. Bugs about attributes don't tend to get > a lot of attention, either in GCC or within standards committees > (the standard form came to C from C++ where all attributes are > unspecified for templates). (wearing my BSI and WG21 committee member hat) I agree it’s unfortunate when stuff gets out of sync and lack of discussion means that a poor solution is implemented. > Which is in part why I view with > skepticism enhancements built on top of the same poorly specified > foundation. (now wearing my system implementor’s hat) Implementations need escape routes to avoid being stifled by the timescales inherent in standardisation. This particular facility (whether considered ill-specified or not) has been in active and successful use from the time of gcc-4.2.1 (and is available to all clang’s platforms - not restricted to Darwin). So, in general, skepticism is reasonable - in this specific case there is usage 'in the wild' for a significant number of years. cheers Iain