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

_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to