Message-Id: <200006132003.QAA28055@qnx.com> Subject: Re: tmpfile in DJGPP To: djgpp-workers AT delorie DOT com Date: Tue, 13 Jun 2000 16:03:15 -0400 (EDT) From: "Alain Magloire" In-Reply-To: <200006131828.OAA07324@envy.delorie.com> from "DJ Delorie" at Jun 13, 2000 02:28:46 PM X-Mailer: ELM [version 2.5 PL0b1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Bonjour > > > We're talking about portability across platforms, where portability > > refers to some std that defines a set of actions that a "portable" > > application can do across platforms. The "bash trick" is portable > > according to such standard. > > If you follow POSIX and ignore non-POSIX systems, you are only > portable to systems that follow POSIX. If you follow ANSI, you'll be > portable to systems that follow ANSI. Etcetera. Well, yes. You are portable according to a set of definitions/API that describe a behaviour: standards. Some OS labels themself as POSIX.1 compliant, XPG4 compliant or just a certain subsets POSIX.4, POSIX.1g, etc ... Maybe we are just confuse on the meaning of "portability". So far, When we've talk about "portability", it was always in regards to ANSI C and POSIX. For example relying on printf ("%q ", ...); is not "portable" meaning in this context It is not covered by the well-known standards, ANSI C, POSIX. It may only work on the *BSD OS. When I write code that will be run on different platforms, I write it with "portability" in mind, so doing fflush(stdin) is not "portable". > > POSIX is not an OS, but an std interface/API that one can choose > > to adhere in trying to create portable code. > > Sticking to POSIX *helps* portability, but there are still too many > non-posix or not-quite-posix systems to *rely* on posix to be > portable. Au contraire, because for exactly of this reasons you have to rely on POSIX for portability. I'm presently working with QNX4, QnX5/Neutrino and they use message passing. The same code should compile on my solaris box, and I have to rely of POSIX behaviour to be portable. Since Solaris, and QNX/Neutrino claim to probide a full compliant POSIX layer. > > > > POSIX is *not* the only game in town. > > > > Well can you cite, any other stds that defines the open()/read() > > write()/link()/unlink() on file descriptors were this is not true ? > > AFAIK, XPG4, POSIX, UNIX9X etc .... is clear. > > MS-DOS, for one. That covers all the Win9x and NT systems also. > Unless, I'm mistaken, again, the scope of the discussion, we're talking portability __across__ platforms not from DOS-5 to DOS-4, or from Win95 to Win98, etc ... In this cases "portability" are gouvern by another set of API that microsoft defines. For example NT offers a POSIX layer on top of there Win32 interface, for ... portability. And I was lead to beleive that CygWin was an effort to provide a POSIX layer on NT. So far I thought one of the goals of DJGPP was to provide a portable POSIX/ANSI layer on top of DOS, yes, they are some areas because of the limitation/implementation of DOS it is not possible, but those standards were the guidelines on the direction to go. > > > Note that POSIX also says that text files are \n, not \r\n, even > > > though ANSI says you can't assume that. > > > > ANSI C and POSIX do not address the same thing nor have the same scope. > > My point was that programs which rely on POSIX may in fact be > violating ANSI, and throwing away some measure of portability that > ANSI grants. I do not beleive that, POSIX(ISO/IEC 9945-1) was written carefully to not clash with ANSI C and in some cases where in may differs for example, the behaviour may change when in a threaded environment, the rationnale is clearly explain. An example is fputc(), where under POSIX to be thread-safe You must lock the stream (flockfile()) POSIX added fputc_unlocked(). meaning some other requirements was impose on those functions, so one is guaranty about there behaviours, but this was clearly stated in the standars and does not affect ANSI C, since it was not written with thread in mind. -- au revoir, alain ---- Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!