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 [EMAIL PROTECTED]
