From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 21 Jun 2003 14:07:12 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 134 ************************************************** Friday 20 June 2003 Number 134 ************************************************** Subjects for today 1 Re: libc : Andreas Buening 2 Re: [EMX] Re: libc : Holger Veit **= Email 1 ==========================** Date: Sat, 21 Jun 2003 01:16:23 +0200 From: Andreas Buening Subject: Re: libc Knut St. Osmundsen wrote: > > Andreas Buening wrote: > > Knut St. Osmundsen wrote: > > > > [snip] > > > > > >>Build system isn't an issue anylonger, and even if it were, there are millions > >>of them (allready responsible for 10+ (closed and open) myself). (If anything, a > >>working GNU make is of much better use than yet another build system - the > >>latest port is leaking a file/pipe handle everytime it's spawning a child, and > >>-j is broken.) > > > > > > Which make version? > $ make --version > GNU Make version 3.79.2a1, by Richard Stallman and Roland McGrath. > Built for i386-pc-os2-emx > [snip] > $ ls -l `which make` > -rwxrwx--a 112288 Feb 20 20:30 G:\GCCOS2\TREE\TOOLS\usr\bin\make.exe Okay. Do you have a simple Makefile file that shows the leakage of file handles? There's currently only one known bug with -j: Under certain circumstaces make just hangs. If you've found another bug could you provide an example, please? Bye, Andreas **= Email 2 ==========================** Date: Sat, 21 Jun 2003 22:39:58 +0200 From: Holger Veit Subject: Re: [EMX] Re: libc On Fri, Jun 20, 2003 at 06:20:19AM -0700, Ilya Zakharevich wrote: > 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.] Not flawed. Proof by example is valid to counter an assertion. > > 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? If you need to recompile stuff anyway, there is no reason to remain compatible to old conventions. > > 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. Effectively, DosOpenL *is* DosOpen *is* DosOpen2 *is* Dos16Open. Follow the traces in the kernel. DosSetFilePtrL is essential, as part of its code is used in DosRead (which is DosReadL). You can also persuade HPFS to use a different blocking size to skip over the 2GB limit. But I guess it is useless to explain you anything, as you are unwilling to accept anything than your own opinion. > > 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. You are repeating yourself. Proof by repetition? > > 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). This is formally correct, but unacceptable for working ports. 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. > > 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 you change headers, you modify semantics. I don't consider this as preserving compatibility anymore. Either the change has no effect on existing code - then why would you do this (other than adding a new function), or it has. > > 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. 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. You will never come to any conclusion this way. > > 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. 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). You might have a small look at some files in the source tree with the innocent extension .cc (exception and new handling). Keep them in there, and you need at least for this two compilers (2.8.1 and 3.x), or leave them out (won't link without removing ordinals), or change them to the libgcc-3.x.a versions (3.x will short-circuit them in EMX*.DLL with the own libgcc.a) and break API compatibility. This can be ironed out, of course, but don't expect anything from me on this anymore. > > 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. Too bad for you. Meanwhile, even Windows has almost managed, thanks to large disk partitions, that the only drive letters the ordinary user knows nowadays are C: for the disk and D: for the CDROM (A: is obsolete, and USB or other external disk devices are handled by some obscure software). Since the CD is now merely a container for newly to be installed software (music is again not handled as files), one can, without restricting generality, say that Windows no longer has drive letters. It understands them somewhere, and if you explicitly ask for them, you can still find them, but it won't need them anymore. Some day they will disappear like a usable DOS box, and noone will miss them. OS/2 is this way no more advanced than CP/M almost 20 years ago which is itself a cheap clone of certain DEC operating systems; cheap in the way that the underlying conventions have been copied without the more fundamental concepts. No one will seriously use EMX for writing "OS/2" software anymore; if at all, programmers keep their copies of VAC++ or Watcom, or maybe even CSET/2 and MASM for that (or stay entirely out of the C/C++ ara and use Java, for instance - ignored here). If there are still efforts, they are concentrating on porting work. Guess where the most important repository for portable software is. So, what tools does one need? > 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. a) and b) is secondary, nice to have, but c) helps the programmer. All the experiments so far aimed at helping the programmer to get some nice software from Unix to OS/2. Now you are proposing that it shoudn't be too easy for the programmer, because he mustn't use an optimally tailored tool for the purpose, but one that is religionusly or politically correct, because it is "compatible". Thank you. Holger