🚀 go-pugleaf

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?

No, but this is widespread.  It broke GUSI something awful.  

For some reason the idea of supplying a standard library that actually
exports the symbols in the standard library was not acceptable to our
friends at Metrowerks.  No idea why.

-- 
Richard Wesley           Electric Fish, Inc.    hawkfish@NeOlSePcAtMricfish.com

"Before we begin our banquet, I would like to say a few words.  And here they
 are:  Nitwit! Blubber! Oddment! Tweak!" - "Harry Potter & Philospher's Stone"

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.

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.

So now...
POSIX is an option globally
Header files are consistent across platforms
Easier to find the correct declaration 
Easier to maintain code and make changes as a user
More POSIX is now available on Macintosh


And there are several other reasons that this approach is better for the
programmer.

Ron

-- 
 "...we feel it's truly the best of the bunch."
Internet Week Reviews...Java Wars 2000
http://www.internetwk.com/reviews00/rev100200.htm

Metrowerks, "Software Starts Here" - Ron Liechty - MWRon@metrowerks.com

In article <301020000939458133%hawkfish@spam.invalid>, Richard Wesley
<hawkfish@spam.invalid> wrote:

>No, but this is widespread.  It broke GUSI something awful.  

I would not say MSL broke GUSI.
If you have a car with 3 tires and someone learns if they sit a weight on
one corner they can drive the car.  Then you put the 4th wheel on and it
throws the balance off,  is that your fault.

>For some reason the idea of supplying a standard library that actually
>exports the symbols in the standard library was not acceptable to our
>friends at Metrowerks.  No idea why.

We are doing it right and if you tapped into Metrowerks non public
undocumented headers and these change that is your own doing.

Ron

-- 
 "...we feel it's truly the best of the bunch."
Internet Week Reviews...Java Wars 2000
http://www.internetwk.com/reviews00/rev100200.htm

Metrowerks, "Software Starts Here" - Ron Liechty - MWRon@metrowerks.com

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

In article <mwron-3010001520420001@c243286-a.bcreek1.mi.home.com>,
MWRon <mwron@metrowerks.com> wrote:

> In article <301020000939458133%hawkfish@spam.invalid>, Richard Wesley
> <hawkfish@spam.invalid> wrote:
> 
> >No, but this is widespread.  It broke GUSI something awful.  
> 
> I would not say MSL broke GUSI.
> If you have a car with 3 tires and someone learns if they sit a weight on
> one corner they can drive the car.  Then you put the 4th wheel on and it
> throws the balance off,  is that your fault.
> 
> >For some reason the idea of supplying a standard library that actually
> >exports the symbols in the standard library was not acceptable to our
> >friends at Metrowerks.  No idea why.
> 
> We are doing it right and if you tapped into Metrowerks non public
> undocumented headers and these change that is your own doing.

GUSI did not tap into non-public headers.  The problem is that the MSL
Pro6 public headers look like this (very roughly):

#if defined(__cplusplus)
inline int fopen (...) {return _fopen (...);}
#else
#define fopen _fopen
#endif

In other words, there is no actual fopen function, nor any way to
create one using the MSL headers - there is only a macro (or an inline
function).  So if you want to use the MW headers to link against a
different implementation provided by someone else, you are SOL, unless
you implement _fopen rather than fopen.  Maybe this is a accepted way
for MW to construct headers for standard libraries, but it sure isn't
very intuitive or useful for some of us.  And maybe this has something
to do with namespaces vs. C linkage (although given the simple aliasing
in the headers i can't see why), but it is sure a pain in the neck. 
Could we at least have an explanation of why this is being done this
way?

And please be careful casting aspersions upon GUSI.  GUSI's file date
functions work, which is more than I can say for the MSL libraries in
Pro 6.   Several folks, including me, have reported this here and to
MW.  stat is one specific example, but there are others.  At the
moment, CWCVS has an #ifdef for __MSL__ == 0x0600 to deal with this
problem.  The constant changes and bugs in these routines have been
driving me and the rest of the MacCVS team quite batty for years, which
is sort of ironic in light of Howard's boast here the other day about
expanding POSIX support in MSL.  

So IMHO, GUSI is not the only thing around here missing a wheel.  GUSI
has its own issues, but to paint MSL as some sort of perfect
implementation is just plain silly.

-- 
Richard Wesley           Electric Fish, Inc.    hawkfish@NeOlSePcAtMricfish.com

"Before we begin our banquet, I would like to say a few words.  And here they
 are:  Nitwit! Blubber! Oddment! Tweak!" - "Harry Potter & Philospher's Stone"

In article <TmBL5.1562$1E.121808@nntp1.onemain.com>, "David Williss"
<dwilliss@microimages.com> wrote:

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

Right this is how it should work,  if you wanted the same functionality
but did not want to define POSIX you could use the leading underscore
version.  (Leading underscores followed by lower case are reserved for
library vendors to avoid conflicts)

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

Do you understand our reasoning now, if you don't agree with it please let
me know.

Ron

-- 
 "...we feel it's truly the best of the bunch."
Internet Week Reviews...Java Wars 2000
http://www.internetwk.com/reviews00/rev100200.htm

Metrowerks, "Software Starts Here" - Ron Liechty - MWRon@metrowerks.com

In article <311020000806020209%hawkfish@spam.invalid>, Richard Wesley
<hawkfish@spam.invalid> wrote:

>GUSI did not tap into non-public headers.  The problem is that the MSL
>Pro6 public headers look like this (very roughly):
>
>#if defined(__cplusplus)
>inline int fopen (...) {return _fopen (...);}
>#else
>#define fopen _fopen
>#endif

NO IT ISN'T  fopen is a standard function and it is not defined in this
way, I just looked.

I greatly respect you but if you want to discuss this you have to be
precise not roughly, but this isn't even roughly it, it is not in the ball
park.  

>In other words, there is no actual fopen function, nor any way to
>create one using the MSL headers - there is only a macro (or an inline
>function).  So if you want to use the MW headers to link against a
>different implementation provided by someone else, you are SOL, unless
>you implement _fopen rather than fopen.  Maybe this is a accepted way
>for MW to construct headers for standard libraries, but it sure isn't
>very intuitive or useful for some of us.  

NONE of this is true,  lets go back to open() which is what I think you
mean to talk about.  What you mention here is exactly what this new
version achieves.  It is ideal for the above scenario for open()  I could
not think of a better instance where this proves the usefulness.

However, this is not true, at all when it comes to the Standard ANSI/ISO
functions this is true that the POSIX functions are conditionalized so
that people that want to use these non standard functions may do so by
undefining POSIX.  GUSI uses POSIX and since we added some it might cause
a conflict with that but I don't see how this is bad at all.

> And maybe this has something
>to do with namespaces vs. C linkage (although given the simple aliasing
>in the headers i can't see why), but it is sure a pain in the neck. 
>Could we at least have an explanation of why this is being done this
>way?

Because it is the right way to do it.  I really don't know how this
affects GUSI or your stuff we can discuss that.

>And please be careful casting aspersions upon GUSI.  

I love GUSI it has done a lot for Metrowerks and a lot for Macintosh
programmers for many years.  If you read this again, I did not mention
GUSI at all,  you were the one that said it broke GUSI but I was talking
about cars.  I think you need to go back and read what I wrote you seem to
have missed the whole point of my little analogy.   

bottom line is by doing it this way if someone wants to define their own
function open or creat or fcntl they can and if they then want to use the
_open they can use that too without having to define POSIX and open it for
every other POSIX function.

The only way this should affect anyone is if they used fcntl.mac.h 
instead of fcntl.h  as a header.  fcntl.mac.h is an undocumented header. 
If they used fcntl.h  then open is defined for them now and was defined
for them previously and will continue to be defined as long as POSIX is
defined (which it is by default)   These new flags are documented int he
MSL C reference now too.

If you want to further this discussion we are very willing to work with
you on this, but I can't discuss hypothetical or non existent conditions.

Ron

-- 
 "...we feel it's truly the best of the bunch."
Internet Week Reviews...Java Wars 2000
http://www.internetwk.com/reviews00/rev100200.htm

Metrowerks, "Software Starts Here" - Ron Liechty - MWRon@metrowerks.com

MWRon <mwron@metrowerks.com> wrote:

> The only way this should affect anyone is if they used fcntl.mac.h
> instead of fcntl.h  as a header.  fcntl.mac.h is an undocumented header.
> If they used fcntl.h  then open is defined for them now and was defined
> for them previously and will continue to be defined as long as POSIX is
> defined (which it is by default)   These new flags are documented int he
> MSL C reference now too.
> 
> If you want to further this discussion we are very willing to work with
> you on this, but I can't discuss hypothetical or non existent conditions.

Don't want to intrude here, but I think (ignore me if I'm wrong) the issue
is that any libraries built with CW5 have to be rebuilt with CW6 if they are
going to be used in a CW6 project.

So for example, GUSI libraries built with CW5 won't work with CW6.

(I am not for one or the other, I just thought I'd pitch in my perspective
on the discussion.)

Steve

-- 
Steve Roy <sroy@mac.com>

In article <B624F315.7277%sroy@mac.com>, Steve Roy <sroy@mac.com> wrote:

>Don't want to intrude here, but I think (ignore me if I'm wrong) the issue
>is that any libraries built with CW5 have to be rebuilt with CW6 if they are
>going to be used in a CW6 project.

I wouldn't know why, you wouldn't link in any MSL function in a library,
not that it doesn't happen.

>So for example, GUSI libraries built with CW5 won't work with CW6.

This might happen but I doubt it because open is a function, although it
is inlined now, that might be a factor.

The bottom line from my perspective is we did this wrong before, and it is
better to do it right now,  instead of continuing a wrong practice.

Ron

-- 
 "...we feel it's truly the best of the bunch."
Internet Week Reviews...Java Wars 2000
http://www.internetwk.com/reviews00/rev100200.htm

Metrowerks, "Software Starts Here" - Ron Liechty - MWRon@metrowerks.com

MWRon <mwron@metrowerks.com> wrote:

> This might happen but I doubt it because open is a function, although it
> is inlined now, that might be a factor.

It does happen. I ran into the same issue myself when converting a project
to CW6. My particular problem was tolower() and toupper(). I was using
third-party libraries that could not be rebuilt, which were expecting
tolower() and toupper() not to be inlined, so the linker was complaining.

I worked around it and it's fine now, by  the way.

> The bottom line from my perspective is we did this wrong before, and it is
> better to do it right now,  instead of continuing a wrong practice.

I agree with that. It's just a transition issue.

Steve

-- 
Steve Roy <sroy@mac.com>

In article <B6258DA8.B01F%sroy@mac.com>, Steve Roy <sroy@mac.com> wrote:

> I was using
>third-party libraries that could not be rebuilt, which were expecting
>tolower() and toupper() not to be inlined, so the linker was complaining.

I think this is a different issue.  C99 allows for inlined functions in C
so we changed several macro's to inlined functions as well as inlined some
others to improve performance of MSL.   

Ron

-- 
 "...we feel it's truly the best of the bunch."
Internet Week Reviews...Java Wars 2000
http://www.internetwk.com/reviews00/rev100200.htm

Metrowerks, "Software Starts Here" - Ron Liechty - MWRon@metrowerks.com

In article <mwron-3110001625120001@c243286-a.bcreek1.mi.home.com>,
MWRon <mwron@metrowerks.com> wrote:

> In article <311020000806020209%hawkfish@spam.invalid>, Richard Wesley
> <hawkfish@spam.invalid> wrote:
> 
> >GUSI did not tap into non-public headers.  The problem is that the MSL
> >Pro6 public headers look like this (very roughly):
> >
> >#if defined(__cplusplus)
> >inline int fopen (...) {return _fopen (...);}
> >#else
> >#define fopen _fopen
> >#endif
> 
> NO IT ISN'T  fopen is a standard function and it is not defined in this
> way, I just looked.

Sorry, typo.  I meant fdopen.  I was just not in the same room with the
white board.  

From cstdio revision 1.16.2.2.6.17:

#ifdef _POSIX
__inline int fileno(__std(FILE) *stream ) {return _fileno(stream);}
__inline __std(FILE)* fdopen(int fildes , char* type) {return
_fdopen(fildes,type);}

#endif

This has implications...

> >In other words, there is no actual fopen function, nor any way to
> >create one using the MSL headers - there is only a macro (or an inline
> >function).  So if you want to use the MW headers to link against a
> >different implementation provided by someone else, you are SOL, unless
> >you implement _fopen rather than fopen.  Maybe this is a accepted way
> >for MW to construct headers for standard libraries, but it sure isn't
> >very intuitive or useful for some of us.  
> 
> NONE of this is true,  lets go back to open() which is what I think you
> mean to talk about.  What you mention here is exactly what this new
> version achieves.  It is ideal for the above scenario for open()  I could
> not think of a better instance where this proves the usefulness.

After checking, it looks like all the examples I have found are POSIX
examples like fdopen, stat and open.  But I am stumped by your claim
that this is ideal.  If I use the MW headers in a project that uses
POSIX calls, they all turn into inline calls to _posix, still a
problem.  

> However, this is not true, at all when it comes to the Standard ANSI/ISO
> functions this is true that the POSIX functions are conditionalized so
> that people that want to use these non standard functions may do so by
> undefining POSIX.  GUSI uses POSIX and since we added some it might cause
> a conflict with that but I don't see how this is bad at all.

That is not the problem.  The problem is that GUSI clients that use the
MW headers in separate compilation wind up generating references to
_posix instead of to posix.

> > And maybe this has something
> >to do with namespaces vs. C linkage (although given the simple aliasing
> >in the headers i can't see why), but it is sure a pain in the neck. 
> >Could we at least have an explanation of why this is being done this
> >way?
> 
> Because it is the right way to do it.  

Um, some more detail?  For example, why is it necessary to use _posix
and posix?  Why can't you just make posix available when POSIX is
defined?

> I really don't know how this
> affects GUSI or your stuff we can discuss that.
> 
> >And please be careful casting aspersions upon GUSI.  
> 
> I love GUSI it has done a lot for Metrowerks and a lot for Macintosh
> programmers for many years.  If you read this again, I did not mention
> GUSI at all,  you were the one that said it broke GUSI but I was talking
> about cars.  I think you need to go back and read what I wrote you seem to
> have missed the whole point of my little analogy.   

I must have, but here is the actual exchange from my news server:

> >It broke GUSI something awful.  
> 
> I would not say MSL broke GUSI.
> If you have a car with 3 tires and someone learns if they sit a weight
> on
> one corner they can drive the car.  Then you put the 4th wheel on and it
> throws the balance off,  is that your fault.

The implication seems to be that you consider using GUSI to be like
using a car with three wheels.  Sorry if I misunderstood, but that is
what it still looks like to me.

> bottom line is by doing it this way if someone wants to define their own
> function open or creat or fcntl they can and if they then want to use the
> _open they can use that too without having to define POSIX and open it for
> every other POSIX function.

But how does one generate links to open using the MSL headers (fdopen
in cstdio to be precise)?

> The only way this should affect anyone is if they used fcntl.mac.h 
> instead of fcntl.h  as a header.  fcntl.mac.h is an undocumented header. 
> If they used fcntl.h  then open is defined for them now and was defined
> for them previously and will continue to be defined as long as POSIX is
> defined (which it is by default)   These new flags are documented int he
> MSL C reference now too.

Sigh.  We are not using this.  The cvs source base (which is including
the MSL headers) knows nothing of these private headers, except maybe
in some Mac-specific modules (which is not where the problems are).

> If you want to further this discussion we are very willing to work with
> you on this, but I can't discuss hypothetical or non existent conditions.

And I appreciate that, but how on earth does one compile POSIX code
using the MW headers and link against a different library?  AFAICT, you
wind up with inlined references to _posix functions, not references to
the actual posix functions.  Which is the gist of my original post.

-- 
Richard Wesley           Electric Fish, Inc.    hawkfish@NeOlSePcAtMricfish.com

"Before we begin our banquet, I would like to say a few words.  And here they
 are:  Nitwit! Blubber! Oddment! Tweak!" - "Harry Potter & Philospher's Stone"

In article <B6258DA8.B01F%sroy@mac.com>, Steve Roy <sroy@mac.com> 
wrote:

> MWRon <mwron@metrowerks.com> wrote:
> 
> > This might happen but I doubt it because open is a function, 
> > although it is inlined now, that might be a factor.
> 
> It does happen. I ran into the same issue myself when converting a 
> project to CW6. My particular problem was tolower() and toupper(). I 
> was using third-party libraries that could not be rebuilt, which were 
> expecting tolower() and toupper() not to be inlined, so the linker 
> was complaining.

Hmph...that explains exactly why our CS department's libraries don't 
work with Pro 6.  Thanks for diagnosing the problem for me. :)

-Eric, who doesn't know how he can solve the problem because he might 
not have source for those libraries....

-- 
Eric Albert         ejalbert@stanford.edu
http://www.stanford.edu/~ejalbert/

Eric Albert <ejalbert@stanford.edu> wrote:

> Hmph...that explains exactly why our CS department's libraries don't
> work with Pro 6.  Thanks for diagnosing the problem for me. :)
> 
> -Eric, who doesn't know how he can solve the problem because he might
> not have source for those libraries....

The solution to my problem was suggested by someone at Metrowerks. I created
a file containing the following code borrowed from MSL and built it as a
library. This satisfied the linker for my old third-party library.

#include <eof.h>

#ifdef __cplusplus
extern "C" {
#endif

int tolower(int c);
int toupper(int c);

#ifdef __cplusplus
}
#endif

extern  unsigned char   __lower_map[];
extern  unsigned char   __upper_map[];

#define __zero_fill(c)     ((int) (unsigned char) (c))

int tolower(int c)
{
    return ((c == EOF) ? EOF : ((int)__lower_map[__zero_fill(c)]));
}

int toupper(int c)
{
    return ((c == EOF) ? EOF : ((int)__upper_map[__zero_fill(c)]));
}

Steve

-- 
Steve Roy <sroy@mac.com>

In article <011120000825248334%hawkfish@spam.invalid>, Richard Wesley
<hawkfish@spam.invalid> wrote:

 
>From cstdio revision 1.16.2.2.6.17:
>
>#ifdef _POSIX
>__inline int fileno(__std(FILE) *stream ) {return _fileno(stream);}
>__inline __std(FILE)* fdopen(int fildes , char* type) {return
>_fdopen(fildes,type);}
>
>#endif
>
>This has implications...

It does if this is C++ as inlines have a different signature for name mangling

>After checking, it looks like all the examples I have found are POSIX
>examples like fdopen, stat and open.  But I am stumped by your claim
>that this is ideal.  If I use the MW headers in a project that uses
>POSIX calls, they all turn into inline calls to _posix, still a
>problem.  
>
> The problem is that GUSI clients that use the
>MW headers in separate compilation wind up generating references to
>_posix instead of to posix.

I'm just not getting this here, these are in the headers so if you include
the header it should be fine I know you have a problem and I'm not trying
to dismiss this, I just am not understanding it.  Maybe you can send me an
example of this.

>Um, some more detail?  For example, why is it necessary to use _posix
>and posix?  Why can't you just make posix available when POSIX is
>defined?

When POSIX is defined the functions are defined in the posix manner.  When
POSIX is not defined the functions are defined in the _posix manner.  The
way it is in CW 6 if you wanted to use your own functions  say, open read
and write  you can turn POSIX off in your prefix file,  but you still can
use _open, _read, _write if you wanted too.  You know have the option of
these even without POSIX on for everything.

I really think maybe your problem is with the inline implementation and
maybe some name mangling are you doing C++.  

>>  I think you need to go back and read what I wrote you seem to
>> have missed the whole point of my little analogy.   
>
>I must have, but here is the actual exchange from my news server:
>
>> >It broke GUSI something awful.  
>> 
>> I would not say MSL broke GUSI.
>> If you have a car with 3 tires and someone learns if they sit a weight
>> on
>> one corner they can drive the car.  Then you put the 4th wheel on and it
>> throws the balance off,  is that your fault.
>
>The implication seems to be that you consider using GUSI to be like
>using a car with three wheels.  Sorry if I misunderstood, but that is
>what it still looks like to me.

Noooo,  MSL was the Car with 3 wheels,  GUSI overcame it with a
counterweight, the new MSL puts the 4th wheel on it.  

>But how does one generate links to open using the MSL headers (fdopen
>in cstdio to be precise)?

I don't understand this, you just call fdopen() as you always did,  you
need to include the proper header but most people require prototypes in C
now.


>And I appreciate that, but how on earth does one compile POSIX code
>using the MW headers and link against a different library? 

You can not use MSL headers to link against a different library, you
should never expect too.  If GUSI has its own POSIX functions you need to
use GUSI Headers and turn POSIX off in MSL Headers.   This works great.   

> AFAICT, you
>wind up with inlined references to _posix functions, not references to
>the actual posix functions.  Which is the gist of my original post.

Not as far as I can tell you just end up with inlined POSIX functions, 
The more this discussion goes on the more it looks like the new C99
inlining is the culprit  and I think this is so much better than macro's
that it is a great addition and long overdue.

Ron

-- 
 "...we feel it's truly the best of the bunch."
Internet Week Reviews...Java Wars 2000
http://www.internetwk.com/reviews00/rev100200.htm

Metrowerks, "Software Starts Here" - Ron Liechty - MWRon@metrowerks.com

In article <mwron-0111001728290001@c243286-a.bcreek1.mi.home.com>,
MWRon <mwron@metrowerks.com> wrote:

> In article <011120000825248334%hawkfish@spam.invalid>, Richard Wesley
> <hawkfish@spam.invalid> wrote:
> 
>  
> >From cstdio revision 1.16.2.2.6.17:
> >
> >#ifdef _POSIX
> >__inline int fileno(__std(FILE) *stream ) {return _fileno(stream);}
> >__inline __std(FILE)* fdopen(int fildes , char* type) {return
> >_fdopen(fildes,type);}
> >
> >#endif
> >

> I'm just not getting this here, these are in the headers so if you
> include
> the header it should be fine I know you have a problem and I'm not
> trying
> to dismiss this, I just am not understanding it.  Maybe you can send me
> an
> example of this.

The current MacCVS source should show it.  <http://www.wincvs.org/>

> You can not use MSL headers to link against a different library, you
> should never expect too.  If GUSI has its own POSIX functions you need to
> use GUSI Headers and turn POSIX off in MSL Headers.   This works great. 

Here is the crux of the problem.

MW considers the MSL headers to be MSL headers.  I consider them to be
standard C headers.  MW gave them the names of the standard headers but
implemented them in such a way as they can only be used with MSL.  This
may be legal, but it is sure a pain in the neck for porting. 

The solution you propose is to use the headers for the actual library. 
That may not be possible because the library may not use its own copies
of the standard C library.  I will check on GUSI when I get a chance (I
gave up and moved on to something else) but at the moment we are all
waiting for Matthias to sort out the mess, and maybe this is what he
will do.

> > AFAICT, you
> >wind up with inlined references to _posix functions, not references to
> >the actual posix functions.  Which is the gist of my original post.
> 
> Not as far as I can tell you just end up with inlined POSIX functions, 
> The more this discussion goes on the more it looks like the new C99
> inlining is the culprit  and I think this is so much better than macro's
> that it is a great addition and long overdue.

For what it does, I can see it is better, but I think that actually
exporting the symbols would be even better.

-- 
Richard Wesley           Electric Fish, Inc.    hawkfish@NeOlSePcAtMricfish.com

"Before we begin our banquet, I would like to say a few words.  And here they
 are:  Nitwit! Blubber! Oddment! Tweak!" - "Harry Potter & Philospher's Stone"

In article <021120000814585412%hawkfish@spam.invalid>, Richard Wesley
<hawkfish@spam.invalid> wrote:

>Here is the crux of the problem.
>
>MW considers the MSL headers to be MSL headers.  I consider them to be
>standard C headers.

There are standard headers in MSL and there are non standard headers in
MSL  we consider the standard headers (both ANSI/ISO and POSIX) as public
standard headers.  

>  MW gave them the names of the standard headers but
>implemented them in such a way as they can only be used with MSL.  This
>may be legal, but it is sure a pain in the neck for porting. 

The problem is that some legacy libraries now no longer link with our
headers since the functions are inlined and we failed to take this into
account.

>For what it does, I can see it is better, but I think that actually
>exporting the symbols would be even better.

We are working on a fix for this and will release it as an update.  There
are several work arounds.  Rebuild the third party libraries so they use
the CW 6 headers  (not ideal since then they may not support older
versions)  write your own set of POSIX using the MSL sources  (not ideal
for anything other than one or two functions)  or for Metrowerks to add
some additional code so that both the _xxxx and the xxxx versions of the
POSIX functions are available using a declexport statement.   This is the
ideal solution but does involve rebuilding the entire MSL Libraries, so it
would probably not be something we'd do until there was another major
update being released.


If anyone has problems with these in the meantime please contact me or
<cw_support@metrowerks.com> and we'll try to get something that fixes the
problems for you.

Ron

-- 
 "...we feel it's truly the best of the bunch."
Internet Week Reviews...Java Wars 2000
http://www.internetwk.com/reviews00/rev100200.htm

Metrowerks, "Software Starts Here" - Ron Liechty - MWRon@metrowerks.com

In article <mwron-0211001305180001@c243286-a.bcreek1.mi.home.com>,
MWRon <mwron@metrowerks.com> wrote:

> In article <021120000814585412%hawkfish@spam.invalid>, Richard Wesley
> <hawkfish@spam.invalid> wrote:
> 
> >Here is the crux of the problem.
> >
> >MW considers the MSL headers to be MSL headers.  I consider them to be
> >standard C headers.
> 
> There are standard headers in MSL and there are non standard headers in
> MSL  we consider the standard headers (both ANSI/ISO and POSIX) as public
> standard headers.  
> 
> >  MW gave them the names of the standard headers but
> >implemented them in such a way as they can only be used with MSL.  This
> >may be legal, but it is sure a pain in the neck for porting. 
> 
> The problem is that some legacy libraries now no longer link with our
> headers since the functions are inlined and we failed to take this into
> account.

Exactly.

> >For what it does, I can see it is better, but I think that actually
> >exporting the symbols would be even better.
> 
> We are working on a fix for this and will release it as an update.  

Great!

> There
> are several work arounds.  Rebuild the third party libraries so they use
> the CW 6 headers  (not ideal since then they may not support older
> versions)  write your own set of POSIX using the MSL sources  (not ideal
> for anything other than one or two functions)  or for Metrowerks to add
> some additional code so that both the _xxxx and the xxxx versions of the
> POSIX functions are available using a declexport statement.   This is the
> ideal solution but does involve rebuilding the entire MSL Libraries, so it
> would probably not be something we'd do until there was another major
> update being released.

We look forward to it.

-- 
Richard Wesley           Electric Fish, Inc.    hawkfish@NeOlSePcAtMricfish.com

"Before we begin our banquet, I would like to say a few words.  And here they
 are:  Nitwit! Blubber! Oddment! Tweak!" - "Harry Potter & Philospher's Stone"