🚀 go-pugleaf

"MWRon" <mwron@metrowerks.com> wrote in message
news:mwron-3010001507480001@c243286-a.bcreek1.mi.home.com...
> In article <8tk79f$2lr$1@mserv2.dl.ac.uk>, "Gareth J Baker"
> <G.J.Baker@dl.ac.uk> wrote:
>
> >There has been a change in fcntl.mac.h in MSL from pro 5 to pro 6. the
> >definition of 'open' in pro 5 is now  '_open' (with an underscore) in pro
6.
> >A definition of 'open' is inlined to _open but only within a #ifdef POSIX
> >construct.
> >
> >Does anyone know any possible reason for this?
>
> First you shouldn't have been using fcntl.mac.h in the first place for
> open(), you should have used the POSIX standard header.   If you had you
> would not have noticed any change.   Metrowerks standard libraries include
> the source and the header files so that users can use them but you should
> not expect any non standard header to be unchanging, that is why we use
> these variations.
>

I don't think he was saying he _was_ using fcntl.mac.h.  If you include
fcntl.h
(the public one) with the right things defined, _it_ ends up including
fcntl.h

In fact, I see the problem he's talking about in the normal fcntl.h, not
just
the private one.  It proptotypes _open, _creat,  and _fcntl, then defines
the correct names without underscores as inlines, but ONLY if POSIX
is defined.  If you don't define POSIX, you don't get them at all.

> Now, if you choose to use the function open in your code you are free to
> do so since it is not an ANSI/ISO function.  However if you want to use
> the POSIX function (which we allow by default) you can use that too.  You
> now only have to change the configuration file and it is fixed for the
> entire library.
>

Wait, you're saing open() _isn't_ ANSI?   Hmmmm... Sure enough.  Acording
to the man page on my Linux system, open() conforms to SVr4, SVID,
POSIX, X/OPEN and BSD 4.3.