🚀 go-pugleaf

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