Re: [jjohnstn@cygnus.com: Re: cygwin/newlib types patchs]

[Christopher Faylor <cgf at redhat dot com>]

On Wed, Mar 28, 2001 at 02:55:30PM +1000, Robert Collins wrote:
>> -----Original Message-----
>> From: Christopher Faylor [mailto:cgf@redhat.com]
>> Sent: Wednesday, March 28, 2001 1:56 PM
>> To: Robert Collins
>> Cc: cygwin-developers@cygwin.com
>> Subject: Re: [jjohnstn@cygnus.com: Re: cygwin/newlib types patchs]
>> 
>> 
>> On Wed, Mar 28, 2001 at 01:46:15PM +1000, Robert Collins wrote:
>> >> What is cygwin-dependent?  Doesn't it make sense to keep 
>> everything in
>> >> one place, even if you have to "#ifdef __CYGWIN__"?
>> >
>> >No. The cygwin-classes and internals aren't newlib specific. The
>> >external interfaces are newlib-specific. As an example, if 
>> Mumit picks
>> >up his glibc port, the cygwin-classes will stay the same, 
>> but the glibc
>> >externals will be needed. Hopefully those external 
>> interfaces are posix
>> >standard and there's no difference :]
>> 
>> Can you give me an example?
>> 
>> cgf
>> (Btw, I've redirected this to cygwin-developers)
>> 
>
>Easily. We use 
>class pthread
>{
>...
>}
>
>within cygwin. That's accessible from several files, so it's in an
>include. The API uses pthread_t everywhere. When building cygwin we want
>typedef class pthread pthread_t;
>when building userland applications we want
>typedef void * pthread_t;
>
>If a different libc is ever used, the userland defines will (should) be
>the same - they are posix derived. The cygwin "kernel" defines should
>follow cygwin1.dll, not libc.

Ok.  I see that linux defines this type of thing in bits/pthreadtypes.h.
I guess our analogy is cygwin/pthreadtypes.h.  IIRC, you were going to
modify cygwin/types.h, which is ok.

cgf