Message-Id: <200006131808.OAA12000@qnx.com> Subject: Re: tmpfile in DJGPP To: djgpp-workers AT delorie DOT com Date: Tue, 13 Jun 2000 14:08:07 -0400 (EDT) From: "Alain Magloire" In-Reply-To: <200006131547.LAA06047@envy.delorie.com> from "DJ Delorie" at Jun 13, 2000 11:47:13 AM 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 > > > > > trick Bash (and other Unix programs) use is inherently non-portable, > > > > Well Eli, I think I have to disagree, non-portable according to what ? > > Non-portable to other OS's besides POSIX ones. I'm not sure I understand you. 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. POSIX is not an OS, but an std interface/API that one can choose to adhere in trying to create portable code. You are more or less guaranty to be OK on an OS if this OS adhere to a certain level of POSIX compliants .... Now, I'm sure this is not new to you .. so I've probably missed something in your comments. > 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. > > > > so I think it's a good idea to remove it even on Unix. > > > > open()/unlink()/close() are very well documented in POSIX. > > It doesn't matter. The fact that we're running on top of a DOS-type > file system limits the amount of posix compliance we can offer. Agreed, I'm no DOS expert, but I can understand that there are certain behaviours that can not be implemented. > 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. AFAIK, ANSI C does not describe the behaviour of API like open()/read() write()/unlink() etc .. It describes a stdio API which is not the same. So if you are talking about tempfile(), printf(), .. ANSI C can be use to describe portability not if you are talking about lower level like read()/write() then Unix9x/POSIX/XPG4 are more relevant. > DJGPP offers as much POSIX > compatibility as possible, given the limitations of DOS, but > programmers still have to be aware of the porting issues. > Agreed, in other words DJGPP is not POSIX compliant on certain "facettes" of its implementation and I beleive they are well documented. -- au revoir, alain ---- Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!