Re: Re: [UnixOS2] libc

On Thu, 17 Jul 2003, Ilya Zakharevich wrote:

> Why should we wait for reports, if we know *beforehands* about the problems?

I don't, that's the problem. :-(
 
> > > Likewise for dlopen().

> How can we appreciate your comment if you refuse to explain *what it
> is going to do*?!  Depending on the semantic you decided to implement,
> different problems will arise.

Let me clarify some things:
- Posix/2 is not _my_ project. In fact, I implemented close to nothing in
  the whole library. Recently, I fixed a couple of bugs that were annyoing
  me and made the fixed version available.
- The only code I actively contributed is for getopt_long (taken from
  BSD) and current libz.
- Mostly, I'm a user of Posix/2 and very happy about it. If it would get
  some more testing (instead of e.g. complaining all the time about
  strcasecmp being missing in EMX), that would help improve it, which I -
  as a user - would of course appreciate. ;-)

> The obvious problem is how to interpret NULL given as the name of the
> library.

Now, that you mention it, I vaguely remember that there is such a problem.
But since that's never used anyway ( ;-) ) what's the point in claiming
that dlopen doesn't work?

> Let me reiterate: this says nothing until you explain what is your design.

Being as BSD-compatible as possible. At least I believe that was the
design by those providing the code (_not_ me).
 
> Now, when one ports an application, *and one cannot avoid* using these
> particular calls, the porters can check whether the calls are used as
> you expected.  If so, then they can use your library.

The problem is, they can't - at least not easily: configure script won't
detect the function thus it will not be used (and in the worst case,
there will be a problem at link time with multiple defined symbols).
 
I do realize that incomplete functions automatically being used also has
a potential of causing trouble. Maybe I'm under-estimating that potential
as practical experiments have been relatively few, but I do have the
impression that it's not as bad as you do believe (and by large).

-- 
Micro$oft is not an answer. It is a question. The answer is 'no'.