On 03.02.2013 19:40, Graeme Geldenhuys wrote:
Did at least the solution help you? AFAIK it should work for FreeBSD as
well as Linux (and maybe the other *nix systems...)
[After my reply to Marco, I tried your solution]
Yes, that did work - thanks. I have never seen those {$} you
mentioned,
On 2013-02-03 18:29, Sven Barth wrote:
>
> Why? The variant with the TYPEDADDRESS should work for the other *nix
> targets as well...
Sorry, I replied to Marco before I tried your solution. Your solution
works. Thanks.
Regards,
- Graeme -
___
fp
On 2013-02-03 18:10, Sven Barth wrote:
>
> 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)"...
+1
> I you look at the POSIX definition at
> http://pubs.opengroup.org/onlinepubs/0
On 03.02.2013 19:23, Graeme Geldenhuys wrote:
On 2013-02-03 18:08, Marco van de Voort wrote:
The resulting overloading can cause problems. It can be reduced by
deprecating the original pascallized versions, and removing them in some
future version.
So at this current point in time, my only so
On 2013-02-03 18:08, Marco van de Voort wrote:
>
> The resulting overloading can cause problems. It can be reduced by
> deprecating the original pascallized versions, and removing them in some
> future version.
So at this current point in time, my only solution is to have code as
follows in tiOPF
On 03.02.2013 19:08, Marco van de Voort wrote:
The resulting overloading can cause problems. It can be reduced by
deprecating the original pascallized versions, and removing them in some
future version.
Maybe exactly that should be done... (a pitty that 2.6.2 is already that
far ^^)
Regards,
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
In our previous episode, Graeme Geldenhuys said:
> In FreeBSD sem_t is pointer. Isn't that what psem_t is for?
No. That is a pointer to sem_t. It doesn't specify what sem_t should be.
struct sem;
typedef struct sem *sem_t;
_sem_ is the record, sem_t is a pointer.
> So under
> FreeBSD sem_t
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
On 03.02.2013 14:16, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
In this case the return type of "@s" will be "^sem_t" instead of
"Pointer" and then the compiler will find the correct method.
Now one might nevertheless ask the question why the compiler considers
the var
In our previous episode, Sven Barth said:
> In this case the return type of "@s" will be "^sem_t" instead of
> "Pointer" and then the compiler will find the correct method.
>
> Now one might nevertheless ask the question why the compiler considers
> the var variant with an "@s" valid at all? May
On 03.02.2013 11:51, Graeme Geldenhuys wrote:
Hi,
I initially posted this in the fpc-pascal list, but I think fpc-devel is
maybe more appropriate, because the pthreads include files might need
amendment.
I personally think that the fpc-pascal list was the more approbiate, but
nevertheless: yo
Hi,
I initially posted this in the fpc-pascal list, but I think fpc-devel is
maybe more appropriate, because the pthreads include files might need
amendment.
I'm trying to get tiOPF to compile under FreeBSD. It works under Linux
and Windows without problems.
I got compiler errors using FPC 2.6.
13 matches
Mail list logo
