Re: Re: [UnixOS2] libc

On Thu, Jul 17, 2003 at 03:38:02PM +0200, Stefan Neis wrote:
> > I see that some kind of mmap()ing is included.  Given no support from
> > the swapper logic, I doubt it "works as designed".  Likewise for
> > shm*().
> 
> Well, no problems have been reported with that code.

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

> > Likewise for dlopen().

> I know that I'm using dlopen/sym/close a lot myself and I don't see, why
> it shouldn't work. ;-)

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.

> If you're alluding to RTLD_LAZY not being supported

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

> I maintain the "works as designed" claim at least for that function

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

> Underline a need for testing. Unless functions like shm* are actually
> available you'll never get feedback on the quality of the implementation
> and missing features.

???  I'm pretty sure that most of the people on the list can guess the
*principal* problems beforehands.  *Given* widely-accepted solutions
(or workarounds) to these problems, one can discuss questions of the
quality of implementation.  However, IMO it does not make sense to
discuss bugfixes for something with major design flaws.

> I prefer to start with the fiction that everything
> just should work and if an application doesn't compile/run as intended,

Sorry, I can't see how these two phrases can survive in one sentence.

If you decide to implement a couple of simple (or juicy ;-) particular
cases of how the function may be used - it is just great.  Put your
solution into a library, document the limitations.

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.

However, the situation is completely different if you include your
function into the C library.  Now ./configure scripts start to detect
the presence of the (non-fully implemented) feature automatically.  Now
they start to use your implementation without any porter's
intervention; they use your implementation even if the application
itself could use some different choice of #defines which would work 100%.

In a ./configure world, only functions with 100% semantic equivalence
should be into the C library.  (At least, this is a noble goal ;-]; in
practice the question of inclusion is negotiable - but functions need
to be *negotiated* on-by-one - or group-by-group.)

Even if an implementation of a function follows the letter of the
documentation, but not the spirit, including it in the C library may
be still questionable.  For example, such is the situation with
mmap() [which cannot implement page discarding efficiently].

Yes, the application which *assume* that mmap() is present become
slightly easier to port (one does not need to add -D_INCLUDE_MMAP
-lmmap to the compile/link line).  But the application for which
mmap() is a *choice* could become unusable: it may have contained an
#ifdef path which works perfectly well with malloc().  However, when
application thinks that mmap() is present, it starts to work very
wastefully in the mmap()-on-OS/2 context.

Hope this helps,
Ilya