|Anonymous | Login||2023-03-22 09:32 UTC|
|Main | My View | View Issues | Change Log | Docs|
|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||2020-04-21 13:41|
|Section||2.2.2 The Name Space|
|Line Number||16061 (TC1) or 16302 (TC2D4)|
|Final Accepted Text|
|Summary||0001071: Name space reservation should move to XBD|
The current text in XSH 2.2.2 reads:
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
Create a new section in XBD after section 12 (Utility Conventions) and before section 13 (Headers) called "Namespace and Future Directions".
In XSH 2.2.2 on page 473, change
Don Cragun (manager)
|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.)|
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.
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.
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.
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
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
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
|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|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|