Re: Re: [UnixOS2] libc

On Fri, Jun 20, 2003 at 02:13:34PM +0200, Holger Veit wrote:
> On Fri, Jun 20, 2003 at 02:15:34AM -0700, Ilya Zakharevich wrote:
> > On Thu, Jun 19, 2003 at 01:43:39PM +0200, Holger Veit wrote:
> > > Do we really want an improvement of the free OS/2 libc (call it EMX or 
> > > different)?
> > > 
> > > If the answer is yes, then we *must* break something in order to
> > > build something better, faster,more powerful (whatever the design goal
> > > 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.]

> If we set off_t to longlong, structures like struct stat will change.
> We could get around with a specific distinction of struct stat and 
> struct stat64, forcing each one to explicitly request the 64 bit APIs.

Correct, without this backward compatibility breaks.

> It is unlikely to happen

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

> so "old" code will still not be able to take
> advantage of JFS or other modern WSEB filesystems.

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.

> There are some more incompatibilities to occur; let's assume setuid()
> and chown()/chmod() would get implemented

I cannot comment on this, since I do not know the semantic of
ownership API on OS/2.  But I see all the reason for these arguments
to be as flawed as your arguments above.

> 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?

> Not only that, some eager porters have used
> #define setuid() (0)
> or similar to get code work; suddenly such software would subtly fail,
> because the process does not get the appropriate privilege and the
> original check whether the process gained setuid privilege from the
> Unix code which would fail on a real Unix is disabled due to that
> (0) return. Consequence: if you want to avoid subtle breaking of the
> code, just avoid putting such code in. Stay with the bugs and problems
> of EMX.

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 this is not sufficient as a proof, I cannot help you.

Well, I did not ask for your help.  I already know your
any-backward-compatibilities stand; many people on this list
understand how wrong and destructive such a stand may be.  I just
wanted to inform *other* people on this list that there is "one more"
people who does not share this stand.

> Besides:
> I don't think anyone needs backward compatibility at all for a DLL which
> is then not even named EMX*.DLL even if it stemmed from EMX and maybe
> shared 90% of the code.

Absolutely.  But my point is that a backward-compatible DLL which
*does* share the name will be many many times more useful - and will
require only minimal work to set up.

> Do you want Unix or EM(i)X?

Sorry, I do not know what is meant by any one of these terms here.
IMO, one of the most devastating point of views of EM's is the
opposition of "OS/2 applications" and "Unix applications" as two
targets for use of EMX.  For me these terms do not mean anything.

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.

Hope this helps,
Ilya