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" <alain AT qnx DOT com>
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
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

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

- Raw text -