Re: Re: [UnixOS2] libc

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:

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.
It is unlikely to happen, so "old" code will still not be able to take
advantage of JFS or other modern WSEB filesystems. One could argue that
we would not need support for this then anyway. So why should we change
anything then? Stay with the bugs and problems of EMX. 

There are some more incompatibilities to occur; let's assume setuid()
and chown()/chmod() would get implemented; 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. 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.

If this is not sufficient as a proof, I cannot help you. 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. Old apps can still resolve against old EMX*.DLLs,
and for new apps one has to clearly decide what he wants - again, see
other posting a question of decision making which is fatally flawed here:
Do you want Unix or EM(i)X? Requesting EMUNIX or UNEMIX is not the answer -
this will never happen.

Holger


Holger