On 8 nov 2006, at 10:42, Ales Katona wrote:
Jonas currently fpc2.1.1 doesn't compile on 2.1.1 with:
rtl/units/i386-freebsd -di386 -dRELEASE ../unix/cthreads.pp
cthreads.pp(252,42) Error: Incompatible type for arg no. 1: Got
"LongInt", expected "Pointer"
So either TThreadID or pthread_t is declared wrongly for FreeBSD
(since that routine passes a TThreadID to a routine expecting a
pthread_t)
Note:
unixtypes thread_t = pointer
No. unixtype includes ptypes.inc. ptypes.inc is OS-dependent. For
*BSD and Darwin, pthread_t (not thread_t) is defined as a pointer.
For Linux it's defined as a cuLong. It's not defined in that file at
all for Solaris, which is a bug I think (it's defined in solaris/
pthread.inc instead).
pthreads.inc thread_t (BSD and linux) = cInt {linux is Longint but
that's just bug)
I don't see this. Afaics, pthread_t (and ppthread_t) is used
appropriately everywhere in pthread.inc for both Linux and FreeBSD. I
didn't check all declarations in detail, but at first sight the cInts
(and longints in Linux) are used where the C versions also return an
int, and not instead of pthread_t.
pthreads.inc thread_t (Darwin) = pointer
Result of pthread_most = cInt
Result of ThreadManager.Killfunctions = DWord
This is some serious mess. First the threadmanager functions need to
return a signed result,
Or possibly a result depending on the OS (just like TThreadID is an
OS-dependent type). I don't know what the Windows versions return.
second the pointer vs cInt stuff has to be
properly cleaned, remove thread_t from unittypes etc.
Sorry, I'm not following the last point. What do you mean with
"unittypes"? The UnixType unit or "types used in various units"? Most
stuff should in fact be based on pthread_t I think, since that's how
the C declaration of those routines looks.
We could define pthread_t as TThreadID to avoid duplication of
information though.
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
