Mail Archives: djgpp-workers/2000/06/13/16:12:10
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 !!!
- Raw text -