Re: Re: [UnixOS2] libc

On Sun, Jun 22, 2003 at 02:58:32PM +0200, Holger Veit wrote:
> > 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?

Yes.  Probably you missed this discussion on the newsgroups: doing tar
-f file fails; doing tar > file failes in EMX-compiled shells; doing
tar >file succeeds from CMD.EXE.

> You are sure that stream I/O doesn't rely on seek/tell anywhere?

???  It works on pipes, right?

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

Well, I do not know which "other" story do you mean. ;-)

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

I do not know what you want to say here.  Depending on
-DEMX_LARGE_FILES and -DEMX_NO_LARGE_FILES, fseek() should mean one of
fseek32() and fseek64().  For backward compatibility, it is convenient
to have -DEMX_LARGE_FILES as default for 2..3 years.  Anyway, these
variables may be set in GCCOPT.  AFAIK, this is what Solaris does; and
I did not see anybody complaining that it is as stupid as...

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

???  It is already there, since all the major players do it this way.

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

The correct behaviour for setuid() is to return -1 unless uid=0.
Since the program in question has no way to get a uid which is !=0,
there is no need to do anything else to port it.

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

I still see no example of how changing the setuid() in the CRT library
will hurt your hypothetical program.

[BTW, *I* would make a wrapper which calls EMX's setuid(), and would
ignore the error if the newuid==olduid==0.  This way I would benefit
from a possible change in EMX's setuid(), *and* get a reasonable
behaviour too.]

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

Sorry, but I have reason to think that I understand "common users"
better than you.  [Of course, this would not stop you from thinking
the same. ;-]

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

Yes, bug-for-bug compatibility is a bad target; and 0.1% of programs
will break no matter how careful you are.  But numbers matter; on many
systems LIBPATHSTRICT will help, and given a very few failing
programs, a wrapper is a viable solution.

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

We all know how much damn you claim you are giving the users of your
software (though I reserve my judgement about how your deeds
correspond to your words ;-).  Personally, I prefer the supplier/user
relationship which is orthogonal to the question of money exchange
(with me on either ends of the pipe).

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

EM's code quality and QA is hard to match without a cooperative effort
- with patches flying through mailing lists - or newsgroups - and
people actually vgrepping them.

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

If such people are indeed "most", too bad for us.  However, I watch
the discussions through serveral portholes, and my (educated?) guess
that the number of such people is well below what one can count on one
hand.  ;-)

Such people are going to exclude themselves from the effort.  But what
matters is how many people *remain*, not how many people are
excluded...

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

[skipped]

I never believed that anything would come out of this (but I hoped
nevertheless that it would).  Actually, I do not remember what it
wanted to be; but IIRC, it tried to solve problems which are mostly
irrelevant (i.e., take very little proportion of porting time) by
making some "magic actions" (like opening a "wrong file"), and by some
pipe dreaming ("let us design a new program loader").

The success of EMX is that it makes things run by a more-or-less
straightforward translation to OS/2 API; there is very few "magic
actions" (the exception is, e.g., the fork() logic).  This way, if EMX
support is not enough for a particular task, you can resolve to using
OS/2 API (since, e.g., file handles are compatible).

> The compatibility trap is deadly for OS/2 or eCS future, as it will 
> severely restrict the options.

Quite the opposite: the fact that your old programs "just work" in the
new environment *opens* options, since of has more resources to make
some new stuff.  I have seen many "let's start from scratch" frenzies;
very few of them succeed; of course, *when* they succeed, it is a
large step forward.

> Technically yes, no doubt. But why didn't it happen then? Don't repeat the
> strawman "no maintainer" argument: it doesn't work

As I said, my believe is that it does.

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

I need a person to coordinate an effort which is much better done by
several people than by one.

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

Sorry for being so stupid, but I still have no idea what you are
talking about...

As I said, the best side of EMX is that due to shallow translation, it
is easy to combine the use of EMX's API with the use of OS/2 API.  Any
such program is neither "Unix", nor "OS/2" (whatever these terms may
mean).  And as I said, any sufficiently advance program/library more
or less *must* be designed this way (to avoid shortcomings of EMX).

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

This is "b" - a limitation of API (e.g., a possible incompatibility of
readlink() and _getdrive()).  [Although I have no idea what you mean
by "backslash path".]

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

Well, I see that on Solaris I use -lz without breaking up the build
system.  Why should z.lib be in libc on OS/2?  Moreover, I do not see
why c.lib should not link with 20 different DLLs (as opposed to 4 or 5
now) - we are not on Unix with its stupid limitation of link_library
== DLL.

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

Do you know Unixish architectures where this distinction is no more?
I do not.  And with long-file-support in many Unices this distinction
is more and more pronounced...

Ilya