>I didn't check how sfio is implemented, but doig it the right way will not
>cause
>problems. Note that there is a weak symbol fopen() and a non-weak _fopen().
>Libschily implements a "fileopen()" that lives besides fopen().
There is no WEAK fopen(), it a normal symbol.
There's also no _fopen(), WEAK or otherwise.
(The C standard prevents people from defining their own fopen() so the
implementation does not have to cater for that eventuality)
The other questions are about "how do you go about fixing X in OS Y"
and claiming that this is somehow a portability issue is one I answered
before.
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.
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.
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.
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 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)
And while I agree that a library (libast or libschily) are a much preferred
over #ifdef HELL, the design considerations should not end there.
On the other hand, ksh93 is pre-existing open source software so we don't
get to revisit the design criteria and that is all fine.
The visibility of an alternate stdio implementation and the alternate
implementation of standard commands still worries me (and not just me).
Casper
Casper
