Re: Re: [UnixOS2] libc

Admin notice: please don't put [email protected] AND [email protected]
into your To: or Cc:, they are the same host, and result in duplicate
postings. One of them is sufficient (os2-unix is of course another list).

On Sun, Jun 22, 2003 at 02:20:51AM -0700, Ilya Zakharevich wrote:
> On Sat, Jun 21, 2003 at 10:39:58PM +0200, Holger Veit wrote:
[...]
> > > 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.

So you just open files and read them sequentially? You are sure that
stream I/O doesn't rely on seek/tell anywhere?

> > > 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 but this is another story. You don't want to see that the whole
"programmers should use different APIs (fseek vs fseek64 or even open/open64)
when they want to read large files" argument is as stupid as Bill Gates'
comment that "640k is enough for everybody". This is a similar attitude as
this technical debate on optimizating the loader by use of ordinals vs.
named entries. The whole OS/2 kernel is full of suboptimal code - if one looked
at the thunking interpreter in DOSCALL1, one would avoid "32bit" Dos* calls
like a plague - topic shift.

Having more than one API for a similar purpose basically results in two
sets of tools; those that deal with small (<2G) files, and others that can
handle big ones. You surely want to add such garbage to autoconf/automake
rulesets, don't you?

[...]
> > 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.

Look at common daemon code that expects *not* to run as root. It issues a
seteuid to become another user (like 'mail' or 'oracle' or whatever) and
the call 
a) fails with -1: correct error check will terminate the program.
b) succeeds, but is a NOOP. Later the deamon code will be very surprised
   to find out it is still 'root': correct error check will terminate the
   program.
If a person porting such a thing want to get it work, he will ignore
the known EMX behaviour and invent an own mechanism that returns the
"correct" behaviour for this process. Maybe by rewriting the logic of the
setuid family at least to the degree needed, or by commenting out error
checks. I don't know how many people have invented workarounds for
prominent problems like strcasecmp, or setuid/setpgrp/setsid, or setitimer.
strcasecmp is among that the most harmless candidate.

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

I and common users don't distinguish between compatibility and compatibility.
The effect is just: this damn thing used to work befor, and now it doesn't
anymore. It doesn't help whether it is then documented.

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

Maybe. Maybe not. But you should not forget that this here is not a 
customer/vendor relation. The customers don't pay any efforts or spent
lifetime to the people who (could) contribute. This in turn means, according
to another proverb: If you pay the orchestra, you decide what they'll play.
Not these other people with their other agendas. As the EMX code is public,
anyone of these can, in full agreement with the GPL, modify anything from
the name to the content. Without any maintainer.

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

If you find such a person, well go ahead. 

> 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

I don't think so. I rather think that most people are afraid that their
contribution will affect the holy grail of compatibility that you and some
more people keep holding high. This is closely related to the question
of acceptance by "the community", or precisely, by a number of speakers
with their own agendas. libemu, or Posix/2, is an example of code that 
was not accepted by the community, in that it was regularly used in ports
and continously improved to weed out the bugs. Why? My opinion is:
it was not fully integrated, and maybe at the moment it would be used, a
better and greater EMX would come up which would obsolete all this. Now,
I doubt that there will be a new EMX "threatening" (by EM, although I can't
read his mind), but the panic of suddenly becoming incompatible with whatever
mainstream one might imagine is a good explanation of why there is no 
forthcoming. It was observable while people waited for the great Windows 95
(which supposedly did no longer rely on DOS), then on Win98 (which supposedly
was more stable because it was not based on DOS), then on WinME (no DOS, for
sure). At the same time, there was a rather stable OS for long already;
you know it, but it was not "compatible". Eventually, there was Win2K
(still not "correct") and WinXP - but meanwhile there is a whole new generation
of software and people forgot about their old software which no longer
works.

Watcom C/C++ is now OpenWatcom, so all complaints that this might have been
a good tool, but yet, it was too expensive are now void. But still it is
not dominant, as it is not "compatible".

Not that anyone now gets the impression that have, within this mail turned from"con-compatibility" to "pro-compatibility" - I am just giving an explantion
that people are trapped by the compatibility curse. M$ did the right thing,
from a technical point of view. They eroded the compatibility issue by
more and more adding new attractive features which forced programmers to
move on and forced users to upgrade.

The compatibility trap is deadly for OS/2 or eCS future, as it will 
severely restrict the options. Now: "deadly" - there is the bad mouth
again: OS/2 is dead. Should say rather: stale mate.

> indicates the opposite: IMO, there are *many* people who can improve
> EMX with a reasonable amount of effort.

Technically yes, no doubt. But why didn't it happen then? Don't repeat the
strawman "no maintainer" argument: it doesn't work: while many people might
not be a genius like EM to invent such a thing from scratch, they can
recompile it at least, with own (maybe just small) improvements. Add
strcasecmp aliases, and call this EMX 0.9d.1, or call it EMU 1.0.0, and
there is public code one epsilon better. Put it up at hobbes, and you are
done? You are not done, because the grail keepers will howl - how can you,
and ordinal 1234 is not okay for strcasecmp, you should better use 2000,
and some code might now no longer compile because there is a 
#define strcasecmp stricmp in it, and anyway, this has discussed for long
and has been reported to EM, and will be done differently in the next EMX
patch, etc. etc. blurb. A technically skilled programmer will dare this
experiment once, and is then cured for ever from walking into an established
minefield.

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

But you need a strawman to distribute this, or literally, burn instead of you?

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

You have a good chance to shoot yourself in the foot when you attempt to
serve two masters.

> > 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 an as clean as possible Unix or POSIX API, so it is documented (this 
   is a) ). The emphasis is on "clean" not "many". I don't care about
   some DOSish APIs like "_getdrive()", as long as they don't disturb
   anything, they may remain there - but if they somehow do (say a
   "readlink() which would return backslash paths) I'd drop them.

> "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.

This effort turned out to be doomed - there is supposedly only one "libc",
not multiple ones. More helper libraries will mess up the build system
at some place.

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

There used to be a distinction between Unix man(2) and man(3), something EMX
to some degree also separates. Provided this would be the borderline, one
would no longer need EMX at all; you could port libc-BSD or glibc on top
of that, and maybe add some OS/2 APIs like EA support afterwards. A design
that scatters hooks into internal structures and APIs all over the code
reminds me too much on the kernel and PMMERGE - IBM's compatibility curses.

Holger