This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: named address space support
On Tue, 15 Apr 2008, Ben Elliston wrote:
> Hi Mark
>
> > I'm not terribly familiar with this proposal.
>
> > Ben, to answer your original question, I don't think that lack of nested
> > address spaces is a fatal flaw, as long as the implementation otherwise
> > meets the spec, and as long as the implementation doesn't somehow make
> > it harder to add that. However, I'd like to know how final this
> > proposal is, and how likely it is to make the WG14 WP.
>
> According to:
> http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=30822
>
> .. the embedded C proposal as of 2008-01-18 is at stage 90.92. This
> suggests that it's very close to being incorporated into the standard.
> Have I understood that correctly?
No. All it means is that TR 18037 is being revised, not anything to do
with the standard. This is a TR Type 2, not an IS, and remains a TR Type
2, not an IS. As I recall, for a long time WG14 had a revised version
fixing problems in the original TR, but trouble getting ISO to accept it;
all the status means is that ISO is now accepting the revised version for
publication. (This revised version is N1275, I think; that should be used
in place of N1169.)
ISO has nothing to do with whether TRs may be incorporated in the standard
in subsequent revisions. It may be involved if a standalone TR changes
into a standalone IS, as was proposed for the draft TR 24747 (special
mathematical functions), but I think that's the only TR related to ISO C
with such a proposal.
There is no C1x draft as yet (N1256, C99+TC1+TC2+TC3, is the base document
for the revision). I don't think it's been decided which TRs might end up
in the base C1x standard, though there's an Austin Group paper arguing
that TR 19769 (u"" and U"" strings) should remain a TR and not be included
in the standard.
I don't know what might be being decided at the Delft meeting right now.
The agenda has "Status of TR 18037" as an unnumbered item.
A TR Type 2 may be considered as indicating "if you want a feature to do
this, it may be a good idea to do it this way and so gain implementation
experience for future standardization". As such, I think it is reasonable
to continue to add features from such TRs to GCC, provided we understand
that they are experimental and may be changed incompatibly in future to
accord with future TR versions or changes in the course of inclusion in
the IS; that unlike actual language standards, we will not try to provide
options to support different versions of a TR in the same compiler
version. (The same applies to informative annexes in an IS, which may
have the same sort of content as a Type 2 TR, such as Annex G in C99.)
--
Joseph S. Myers
joseph@codesourcery.com