Date:	Tue, 13 Jun 2000 14:28:46 -0400
Message-Id:	<200006131828.OAA07324@envy.delorie.com>
From:	DJ Delorie <dj AT delorie DOT com>
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

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

- Raw text -