Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001071 [1003.1(2013)/Issue7+TC1] System Interfaces Comment Enhancement Request 2016-08-25 17:17 2024-06-11 08:55
Reporter nick View Status public  
Assigned To
Priority normal Resolution Accepted  
Status Closed  
Name Nick Stoughton
Organization USENIX
User Reference nms
Section 2.2.2 The Name Space
Page Number 473
Line Number 16061 (TC1) or 16302 (TC2D4)
Interp Status ---
Final Accepted Text
Summary 0001071: Name space reservation should move to XBD
Description The current text in XSH 2.2.2 reads:

The prefixes posix_, POSIX_, and _POSIX_ are reserved for use by POSIX.1-2008 and other POSIX standards.

However, this is in a section that is very C-language specific, and it is desirable to reserve namespace for other things like environment variables, functions in awk scripts, shell long options, etc. and it is unclear if this reservation extends to these.

Future versions of this standard need to be able to invent new names where there exists multiple, differing, implementations of something with the same name, or an existing method needs to be enhanced in an incompatible way
Desired Action Create a new section in XBD after section 12 (Utility Conventions) and before section 13 (Headers) called "Namespace and Future Directions".

In order to prevent future versions of this standard from introducing features that could cause older applications to fail, the prefixes posix_, POSIX_, and _POSIX_ are reserved for use by this standard for any name (e.g. function, variable, command etc.). Neither implementations nor applications shall introduce objects in this namespace.

In XSH 2.2.2 on page 473, change

The prefixes posix_, POSIX_, and _POSIX_ are reserved for use by POSIX.1-2008 and other POSIX standards.

to

As described in <<xref to XBD 13 Namespace>>, the prefixes posix_, POSIX_, and _POSIX_ are reserved for use by POSIX.1-20XX and other POSIX standards.
Tags issue8
Attached Files

- Relationships
related to 0000901Closed reserve _POSIX* shell option namespace for future use 

-  Notes
(0003907)
Don Cragun (manager)
2018-01-04 17:44

Although we are reserving these namespaces for use by the standards, we realize that there is some existing practice using some names in these namespaces. Since these namespace reservations won't be formal until Issue 8 is adopted and we plan to start using some names in these namespaces in Issue 8, we will attempt not to break existing code while producing Issue 8 of the standard. (We try to avoid name collisions even when there are namespace reservations anyway, but there is always a chance that we will pick a name and not know that the name has been used for some other purpose.)
(0004023)
kre (reporter)
2018-05-09 11:45

The whole idea of reserving namespaces is fundamentally broken - it was realising that which
caused the IETF to drop the "X-" e-mail header convention that had existed in earlier e-mail standards
but is now gone.

The convention (whatever namesoace is reserved this way) isn't so bad when the authority is one
which simply invents new technology of its own volition, then expects that to be implemented.

But for standards bodies like the IETF, and here, which expect to standardise what exists in the
wild (what has been implemented, and had become common - leaving aside whether that is
still true, in any sense, in the IETF) it creates a catch-22.

An external implementation cannot implement anything using the reserved namespace, as it
is reserved, so they use something else instead. The standards body cannot standardise anything
new using the new namespace, as there are no implementations of the new technology using
that namespace - they all use something different.

For issue8, it would be better to simply drop the whole idea, rather than broadening it.
(0004026)
shware_systems (reporter)
2018-05-10 14:52
edited on: 2018-05-10 14:54

Any implementation in the wild is fundamentally the same whatever names are chosen to implement it. The time for introduction of names using the reserved prefixes is therefore in the proposal for adding it to the standard, where the risk of conflicting usage of the wild names is significant. Platforms using the new names will still have to be recompiled to a new point release simply because POSIX_VERSION will get bumped also; it is up to them to advertise properly applications using the wild version would need refactoring/compiling also to be conforming once a proposal is approved for being in that next release. There is no Catch-22, from this standard's perspective, just a matter of following reasonable procedures.

(0004029)
kre (reporter)
2018-05-11 10:06

It isn't the platform that matters, but the users' scripts.

Take a real example - many shells implement the "pipefail"
option, which alters the way the shell determines the exit
status of a pipeline.

That's now common enough that it could be standardised (maybe
there's an issue requesting it - this is not intended to be
that - and it doesn't matter for this purpose).

If we were to say "that's not a posix reserved name, we would
have to call it _posix_pipefail" (or something like it) it would
be useless - all the scripts that use it do "set -o pipefail".

What's more, changing its name would be dangerous, no shell
that currently implements "pipefail" can ever drop support
for that name - because the users use it. But if it isn't
standardised, they also have no reason to make that option
conform to what the standard actually specifies for the new
option - they could implement a conforming _posix_pipefail
(which nothing uses) and leave the old one being similar,
but perhaps slightly different. That's exactly what
standardisation is supposed to avoid.

The correct route of course would be to simply define what
the "pipefail" option is supposed to be (what effect it has)
using that name and taking account of what is common between
the implementations. Any shell that wants to conform would
need to make that option work the posix way (at least in posix
mode.) That is how it ought to be.

That is, the _posix_* namespace is simply useless, unless
something new is to be invented. And that should not happen
(except perhaps for some indicator to indicate that some other
feature exists - so perhaps a _posix_pipefail variable might
get set if the pipefail option exists .. except that would be
invention, as no implementation I have seen does that, and as
the name is reserved, nor can they while also conforming.)

And while (if it worked) namespace divisiion would solve name
clashes between posix and the implementations, it doesn't solve
the clashes that matter, between different implementations, and
between the implementations and the users - they still all use
whatever they want (excepting only the _posix_ names) and
implementations can clash with each other and with scripts - the
world manages to deal with all of that - people don't always
like it, but there is no workable better way.

This same kind of thing is true of all attempts to divide namespaces
between "us" and "them". Unless "we" ("us") are in the business of
regularly inventing new stuff, we have no need for new names, and so
we have no need of a reserved namespace. If we are just writiing
down what others have already invented, we *must* use their names.
If that would cause too big of a problem, then whatever it is is not
ready to be standardised.

ps: Please do not use this note as a trigger for discussions of the
pipefail option ... that is just an example for this note.
(0004033)
joerg (reporter)
2018-05-14 10:59

The intention of the posix prefix is to be able to include a feature that has
been implemented in a non-unique way in different shells.

If such a problems exists, POSIX could chose one of the implementations or
a better combination from all existing implementations ans introduce it under
the name posix_xxx
(0004035)
kre (reporter)
2018-05-15 22:22

Re Note 4033

First, before anyone draws any incorrect conclusions from this
note, I am very much opposed to creating any rules to attempt to
limit future solutions to any problem - each should be considered
entirely upon its merits to find the best solution, unencumbered by
any "we cannot do this, because we decided..."

That said, let's consider a few possibilities for what might happen:

First, if multiple implementations (this includes anything, not just
features in shells) might implement different things and call it by
the same name (a namespace collision). This isn't really a case
considered in the note, or the bug report, but is related (kind of) so
I am including it here... It isn't (wasn't) considered as it
really is a different issue - each of the features would need to be
considered independently. If one (functionality, not name) is
implemented multiple times, and is worthy of being included, then it
should be using a name which one of the other implementations has
chosen rather than the one that conflicts (if at all possible). If
the function has been implemented multiple times, all with the one
name, that happens to have been used elsewhere for something different
then it should just be standardised under the common name, and the
implementations that used the name for something else need to change
(but this should be a last resort.)

If several implementations have implemented substantially the same
functionality under the same name, then it should just be standardised
under that name (with the common parts of the functionality specified,
and less common parts either unspecified, or if essential, then as
most commonly implemented.)

If there are variant implementations of some functionality under the
same name, such that the common part is so limited as to be useless,
then it is not ready to be standardised, and the implementations should
be encouraged to converge upon a more functional common set of
features.

What should never be done is "a better combination from all existing
implementations" - that's invention, and without implementation
and use, it is only guesswork as to whether what is specified will
actually be useful or not. That we should avoid - always.
Simply note the problems, and leave it for the implementations to
come up with solutions that work, and once there is something,
then it can be included. Included using the name actually used in
the implementation(s?) - if that happens to be posix_xxx then fine,
otherwise, just xxx.

Again, these are nothing more than general principles, not rules, in
any particular case, what should be done will depend upon the actual
issues, and what implementations actually exist, and how they are
actually used.

- Issue History
Date Modified Username Field Change
2016-08-25 17:17 nick New Issue
2016-08-25 17:17 nick Name => Nick Stoughton
2016-08-25 17:17 nick Organization => USENIX
2016-08-25 17:17 nick User Reference => nms
2016-08-25 17:17 nick Section => 2.2.2 The Name Space
2016-08-25 17:17 nick Page Number => 473
2016-08-25 17:17 nick Line Number => 16061 (TC1) or 16302 (TC2D4)
2016-08-25 17:17 nick Interp Status => ---
2018-01-04 17:09 nick View Status private => public
2018-01-04 17:23 nick Relationship added related to 0000901
2018-01-04 17:44 Don Cragun Note Added: 0003907
2018-01-04 17:44 Don Cragun Status New => Resolved
2018-01-04 17:44 Don Cragun Resolution Open => Accepted
2018-01-04 17:44 Don Cragun Tag Attached: issue8
2018-05-09 11:45 kre Note Added: 0004023
2018-05-10 14:52 shware_systems Note Added: 0004026
2018-05-10 14:54 shware_systems Note Edited: 0004026
2018-05-11 10:06 kre Note Added: 0004029
2018-05-14 10:59 joerg Note Added: 0004033
2018-05-15 22:22 kre Note Added: 0004035
2020-04-21 13:41 geoffclare Status Resolved => Applied
2024-06-11 08:55 agadmin Status Applied => Closed


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker