Re: Re: [UnixOS2] libc

On Sat, Jun 21, 2003 at 10:39:58PM +0200, Holger Veit wrote:
> > > > > is). This is the unavoidable price to pay.

> > > > Now try to prove this.  AFAIU, your argument looks very much like bullying.

> > > Proof by example:

> > It is by example, it is not a proof.  [Not mentioning that the example
> > is flawed.]

> Not flawed. Proof by example is valid to counter an assertion.

I disagree with both parts.

> > > It is unlikely to happen

> > What is "it"?  People putting -DEMX_LARGE_FILES into GCCOPT?

> If you need to recompile stuff anyway, there is no reason to remain
> compatible to old conventions.

Since one does not need to recompile in most of the situations (i.e.,
when one does not need off64_t), there is every reason.

> > To take advantage of large files, one needs to use DosOpenL().  Using
> > L-version of seek()/tell() is secondary; moreover, no EMX_LARGE_FILES
> > is needed to support applications which do not need to seek far.

> Effectively, DosOpenL *is* DosOpen *is* DosOpen2 *is* Dos16Open. Follow the
> traces in the kernel.

I do not care about "effectively".  If one does not use DosOpenL(),
one can't read/write files above 2G.  I do not see why any other
argument is relevant.

> You can also persuade HPFS to use a different blocking size to skip
> over the 2GB limit.

On DASDs - yes.  Of course, not on files.

> > > thus an awful lot of software would suddenly underlie file
> > > protection effects, including the effect that former NO OPs (like
> > > setuid()) that simply returned 0 for success, will now fail.
> > 
> > Is setuid() implemented by EMX?  Do you say it did not return -1 when
> > uid != 0?
> 
> misc/setuid.c return -1 (EINVAL).

Thanks, I can't check this now (this laptop has no EMX source).

> This is formally correct, but unacceptable for working ports.

This depends.  Nobody complained about Perl (but Perl is a special
point, since one can edit a Perl script to avoid these calls).

> The pair getuid/setuid may return or expect uid=0 all the time, but
> not all software delivers this uid. Also code the changes the uid
> (seteuid/reuid, etc.)  might later expect that the returned is no
> longer 0. The whole system works for nice weather conditions
> only. Result for porting: short-circuit these functions and adjust
> stuff as needed.

Then I see no reason why changing EINVAL return to anything else may
break anything.
 
> > I do not follow your arguments.  Did you say:
> > 
> >   There are some broken ports lying around.  Recompiling such a port
> >   with new, more correct, headers/libraries will require some work.
> > 
> > If yes, I do not consider this as a valid argument against correcting
> > headers/libraries.
> 
> If you change headers, you modify semantics. I don't consider this as
> preserving compatibility anymore.

There is a compatibility and compatibility.  Making a former error
condition into something which is documented it might have happened is
of the latter ;-) kind.

> Then solve the EMX problem yourself. As you were asking for - clearly 
> spoken - for a *victim* who should take over EMX so that you can add *your*
> ideas and changes, don't count on me on the issue of EMX changes (which
> should not change anything) any longer.

???  I never counted on you.  You made your stand quite clear many
years ago already: you are interested in "vertical" applications only.
When you deliver a "turnkey" solution, your approach of "breaking
everything as far as it is not seen if one uses your software only" is
quite viable.  No argument about this.

But other people have other agenda.  They need different approaches.

Of course, if the "victim" would benefit from my "ideas and changes"
only, then this would be a kind of a skewed relationship ;-) - I would
provide all the changes, and all that the "victim" would do is
bothering me to make things better.

But there is another fundamental difference between you and me: it
looks like you believe that you (and me? ;-) are the *only* persons
capable of a contribution to EMX.  My wish for coordinator clearly
indicates the opposite: IMO, there are *many* people who can improve
EMX with a reasonable amount of effort.

I even believe that there are many people who "sit" on
(almost-)ready-to-distribute solutions to EMX problems (like I do).

> Feel free to do so. Be aware that you need some considerable modifications
> alone to get EMX to work *correctly* with any gcc > 2.8 (or 2.9).

I see no reason to upgrade gcc from 2.8.1 (for the purpose of EMX buld).

> No one will seriously use EMX for writing "OS/2" software anymore.

I would say more: I never saw any reason to write OS/2 software at all
(with a possible exception of WPS enhancers).  Why confine yourself?

> > We are discussing APIs.  The targets are:
> > 
> >   a) Have APIs conform to the documentation as much as possible;
> > 
> >   b) Have the documentation conform to standards as much as possible;
> > 
> >   c) Have support for as many APIs' entry points as possible.
> > 
> > I just do not see where the opposition of Unix/OS2/EMX comes into this
> > picture.

> ANSI != POSIX. 

???  So what?

> a) and b) is secondary, nice to have

For me a) and b) are tantamount.

> but c) helps the programmer.

Without a and b "c" is useless - what good is a feature if you do not
know what it will do.  Without "c" one needs to reinvent the wheel
again - pitiful work, but doable.

"c" is nice to have, no more.  And if one can add "c" via an external
library, with no support from EMX, there is no need to mix this into
the current discussion.

Of course, it does make sense to discuss which hooks one needs to add
to EMX to simplify addition of externally supported enhancements...

Hope this helps,
Ilya