🚀 go-pugleaf

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"