Subject: Re: Re: [ksh93-integration-discuss] comments on rev 287 makefiles
--------
Casper.Dik at Sun.COM wrote:
> There are several reasons why one would like to reimplement certain
> functionality:
>
> 1) There is no standard way of doing things
> 2) The standard way of doing things is "broken"
> 3) The standard way of doing things is marred by bad
> implementations
> 4) Not everyone implements the standard way of doing things, yet.
You left out
5) Extending the standard provides needed functionality without
having to create new interfaces. An example of this would be
printf() extensions using the printf() interface.
Another example is the regcomp() interface which doesn't handle
shell patterns in the standard but does in the AST version.
>
> Each of these require a different approach.
>
> 1) You'll have to invent your own.
> 2) You'd have to argue *really* hard to convince people of
> this and then propose things to improve upon the current
> standard. Rolling your own is generally not an option.
> 3) Here, I think, the proper course of action is reimplementing
> the standard version and using that on systems with a broken
> implementation.
The ways we handle #3 is to use feature testing to see whether the
implementation is broken and only override the implementation when
it is broken. The AST library contains a number of functions that
are only brought in by broken implementations.
> 4) Implement (parts of) the standard solution on non-standard
> functionality offered on the respective platforms.
>
>
> NSPR was faced with problem #4 but chose to go a route which was only
> appropriate for #1
>
> Sfio looks more like #3 than #2, though I'm not sure. It certainly isn't
> #1.
It is actually a combination of #2 and #5. However, by using #1
(inventing SFIO), we were able to provide a thin layer to provide
the STDIO functionality and obtain both source and binary compatibility.
>
> Performance is hardly ever a good reason to argue #2; performance is
> generally a quality of implementation issue, not a problem caused by
> standards.
This is usually the case. However, if a really bad implementation
of malloc() were provided so that the resulting application were
nearly useless, I would treat this as #3.
>
> (This is also why I'm not happy about any (most) of the shell built-ins;
> they should share a common implementation with the Solaris commands of the
> same name or they should not be built-ins at all)
>
I would love to have a common implementation for commands and built-ins.
However, noone had previously defined the rules for writing commands that
could be run either as stand-alone or as built-ins. We defined a set
of rules for this and wrote all the commands in libcmd to obey
these rules and to be a superset of POSIX and GNU functionality.
If you use the same rules, or start from our implementation and
add Sun specific extensions, you could replace the commands in
/bin and have then run either as built-ins or as stand-alones.
Finally, although this is off topic, let me comment more about reason #5.
I believe that this is the avenue that is likely to make the most progress.
However, it is also the cause of much of the incompatibilities between
systems. What is needed is the ability for some group to take the list
of incompatible extensions, select the appropriate one and then
standardize this one.
There have been several examples in which this approach has worked:
1. The Bourne shell vs. the Mashey shell. Both were extensions
to the Thompson shell. After a number of heated discussions
a committee was set up to select the one that would survive
and what it would have to absorb from the other. The result
was the System V shell. Tools were provided for migration
from the Mashey shell to the System V shell.
2. The ANSI-C standard.
3. The original POSIX standard unified BSD and AT&T UNIX.
Could the same be done today?
1. Could ksh, bash, and zsh create a common shell standard?
Fortunately, because of some communication between the authors
the divergence hasn't been too great so it might be possible.
2. A replacement for the standard make. Is to possible to unify
nmake, gnu-make, smake, ... into a single make. Glenn Fowler
developed an intermetidate make format that could be used to
convert all the current makefiles into a single specification.
It would take a group consisting of the various make creators
to work together to make this happen.
David Korn
dgk at research.att.com
