Email List: Xaustin-group-lX
[All Lists]

Re: Other standards with names encroaching on POSIX reserved symbols

To: austin-group-l@xxxxxxxxxxxxx
Subject: Re: Other standards with names encroaching on POSIX reserved symbols
From: Martin Sebor <sebor@xxxxxxxxxxxxx>
Date: Sun, 06 Jul 2008 16:50:14 -0600
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding:sender; bh=4h74+2JotMGDDbL8CerSDFmxv8Gn3NBQH9wJyybLe6Y=; b=HPDw3qc2WaU2F+Il8iYfF63uTAZet9MSzOTnHb3tss/91w8BFVuj+NJOjQS+EiuAnC v8h2ppRZUC5SbyAZzym7HaYjrAPJ+QIJgS2iLPswGpmV4oMJZuTfaKPGXPVDPKXzTmSz iOaJR8yw367blx5ut5a/gHOCvjhXj6i5TrDJ8=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding:sender; b=K87dQhxtGRKIVEwgj1yR5VtSnU+MR9oK1lx6W+JRlZZvsLMGiZUCIePIPFsUiejEMJ ni73k2CJgyzQL7n93iOKk+40E4Pb8CCYBbjVsghkM6KIQLDMidgHD2k8csrPbYSE0UuH H/tnleQjrwUGqQvt2Yju1VV7vuD3PEXDlbwZU=
Organization: Rogue Wave Software, Inc.
References: <1215105917.3898.68.camel@amstaff2.msbit.com> <20080704090015.GA30577@squonk.masqnet>
Geoff Clare wrote:
Nick Stoughton <nick@usenix.org> wrote, on 03 Jul 2008:
The C++ standard currently (in the 1998 and 2003 editions) has some
typedef names that overlap into the POSIX reserved namespace rules (XSH
2.2.2). In particular the reservation of "_t" for ANY header (D5.1, page
472, line 16036) collides with some some of the names in C++.

In the new revision, C++0x, further names are being proposed in this
space.

My belief is that the namespace is reserved for implementation and
standards use.
There is a subtle difference between reserving a namespace for
standards use, and reserving a namespace for implementation use but
also defining some standard identifiers in that namespace.  What
POSIX does is mostly the latter.  The only namespace it reserves
purely for standards use is the prefixes posix_, POSIX_, and _POSIX_.

So unless C++0x defines names beginning with posix_, POSIX_, or
_POSIX_ (which seems highly unlikely), I believe there is no conflict
between C++0x and POSIX here.  The only potential conflict is between
C++0x and individual POSIX implementations, but that is no different
from the potential conflict when a POSIX revision adds new standard
names in a namespace it reserved for implementation use.
FWIW, I believe there is an important difference here.

Assume the namespace *_t (for example) is reserved for POSIX
and its implementers alone, and not intended to be used by
other standards.

When introducing a new name into the reserved namespace, POSIX
(the spec) need concern itself with causing conflicts with its
existing implementations but POSIX implementers need not worry
about any conflicts at all.

Now assume that other standards besides POSIX are permitted to
introduce their own names into the same namespace.

Both the authors of POSIX (the spec) and its implementers must
make sure that new names introduced into this namespace (either
as standard names or as implementation-defined extensions) don't
cause conflicts with other standards besides POSIX as well.

Martin


I'd like to be able to give an official liaison statement back to the C
++ committee that blesses what they've done/are doing. Specifically:

1. It is OK for the C++ standard to use the names listed in the attached
email.
Agreed.

2. Provided that appropriate due diligence is done to ensure that no
existing applications or implementations are broken, they may use other
names (e.g. *_MAX) as they see fit.
They may use other names as they see fit, as long as they don't begin
with posix_, POSIX_, and _POSIX_.  The due diligence is up to them,
not something we can impose on them.

3. Request that they inform us of such names they are planning to use,
for liaison purposes (this is part of the due-diligence against breaking
stuff, and so that we realize what a particular name is being used for
in a different standard).
This applies equally well to any additional names, not just those in
reserved namespaces.






<Prev in Thread] Current Thread [Next in Thread>