Date: Tue, 13 Jun 2000 14:28:46 -0400 Message-Id: <200006131828.OAA07324@envy.delorie.com> From: DJ Delorie To: djgpp-workers AT delorie DOT com In-reply-to: <200006131808.OAA12000@qnx.com> (alain@qnx.com) Subject: Re: tmpfile in DJGPP References: <200006131808 DOT OAA12000 AT qnx DOT com> 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 > 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. > 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. > > 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. > > 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.