[fpc-devel] how to get same pthreads code to compile between Linux and FreeBSD

[Sven Barth]

On 03.02.2013 18:54, Graeme Geldenhuys wrote:
> On 2013-02-03 12:28, Sven Barth wrote:
>>
>> I personally think that the fpc-pascal list was the more approbiate, but
>> nevertheless: your problem comes down to this code (in principal):
>
> I thinking was that this problem seems to point towards a bug, or at
> least inconsistency between defined types and various platforms. But as
> you say, nevertheless.  Thanks for replying.
>

I personally still think there is a bug, because the compiler should (in 
my opinion) not consider "sem_init(@sem)" a valid usage of "sem_init(var 
sem: sem_t)"...

>>
>> type
>>     sem_t_rec = record
>>     end; // from rtl/freebsd/ptypes.inc
>>     sem_t = ^sem_t_rec; // from rtl/freebsd/ptypes.inc
>>     psem_t = ^sem_t; // from packages/pthreads/src/pthrbsd.inc
>
>
> Indeed, the sem_t is differently defined between Linux and FreeBSD.
> Under Linux, sem_t is just a record defined as:
>
>    // rtl/linux/ptypes.inc
>    sem_t = record
>       __sem_lock: _pthread_fastlock;
>       __sem_value: cint;
>       __sem_waiting: pointer;
>    end;
>
> In FreeBSD sem_t is pointer. Isn't that what psem_t is for? So under
> FreeBSD sem_t should be defined as
>
>    sem_t_rec = record
>    end;
>    sem_t = sem_t_rec;
>    psem_t = ^sem_t;
>

I would say that someone wanted to "honor" the "obfuscated type" idea of 
that structs... don't ask me why it was done that way though

>
>
> I would expect unix-types / posix-types supposed to be defined the same
> in all such related OSes (eg: *BSD, Linux, MacOSX, Haiku, *nix)?

I you look at the POSIX definition at 
http://pubs.opengroup.org/onlinepubs/007904975/basedefs/semaphore.h.html 
you'll see that they don't specify any specific fields so sem_t should 
be treated as opaque type and thus any kernel can implement it as it 
sees fit.

>
>
>> Now the problem is the "@s". This returns type "Pointer" and now you
>> have two pointer types: sem_t and psem_t. Thus the compiler can not
>> resolve this.
>
> Indeed. You just seem to have explained it better than I.

Did at least the solution help you? AFAIK it should work for FreeBSD as 
well as Linux (and maybe the other *nix systems...)

Regards,
sven