🚀 go-pugleaf

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