Hi all.

On an OpenSuse 12.1, Lazarus 0.9.31, FPC 2.4.4 I can't create a semaphore Code:

     LockerS: Integer;
     SemKey: Integer;
       SemKey := strToIntDef(ESemaphoreKey.Text, -1);
       if SemKey = -1 then
         Break;
       LockerS := semget(SemKey, 1, 0666 + IPC_CREAT + IPC_EXCL);
       if LockerS >= 0 then begin
         // got the semaphore: initialize it
         Args.Val := 1;
         Ret := semctl(LockerS, 0, SEM_SETVAL, Args);
         if Ret >= 0 then begin
           // semaphore locked; get out
           Operation.sem_op := -1; //reduce the semaphore count to lock
           Operation.sem_num := 0; //signifies 0th semaphore
           Operation.sem_flg := IPC_EXCL;  // fail if key exists
           Ret := semop(LockerS, @Operation,1);
           if Ret >= 0 then
             Break;
         end
       end else begin
         LastError := errno;
         LastErrorText := strerror(LastError);
         Memo1.Lines.Add(Format('semaphore locker not created
errno:%d-%s', [LastError, LastErrorText]));
       end

*semget *always returns -1 with errno set to 2 (?) whatever the contents of *SemKey* could be.

What is wrong ?

Antonio.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120216/496bedc4/attachment.html>

According to
http://pubs.opengroup.org/onlinepubs/7908799/xsh/semget.html error 2 means the following:

[ENOENT]
A semaphore identifier does not exist for the argument key and (semflg&IPC_CREAT) is equal to 0.

Can you try to use "or" instead of "+"? Also you're trying to pass a C style octal number. Replace the leading zero by a "&" which is the equivalent declaration for Free Pascal (see also here: http://www.freepascal.org/docs-html/ref/refse6.html ).

Regards,
Sven

Sven Barth wrote

Can you try to use "or" instead of "+"? Also you're trying to pass a C style octal number. Replace the leading zero by a "&" which is the

you mean '$' of course ;)

L.

D'oh, sorry you mean '&' actually... :(
L.

There is never a end to lerning. ;) From now on you'll know that FPC supports &[0-7]* for octal and %[0,1]* for binary numbers ^^

Regards,
Sven

Le 16/02/2012 17:13, Sven Barth a ?crit :

Obviously I was too tired to read all the words :'(

You are absolutely right and it works: really very nice 8-) Thanks to you two, Sven and Lukasz

I would have deleted my posting if gmane servers supported that ;) L.

Hi again.

I've a problem with IDE (0.9.31 2011/12/05 Linux OpenSuse 12.1, FPC 2.4.4, GTK-2:
when double-click on the event name of a TButton in the object inspector trying to generate the procedure event code, the unit "ipc" is open and the error "/usr/share/fpcsrc/rtl/unix/ipc.pp(119,9) Error: expected end., but seq found" is displayed in the errors window Same behaviour when hitting Ctrl+Space to end the code for a variable

This is the code snippet from ipc.pp tagged by the IDE
105     {$if not defined(linux_ipc32) and not defined(FPC_USE_LIBC)}
             TIPC_Perm = record
                 key   : TKey;
                 uid   : kernel_uid_t;
                 gid   : kernel_gid_t;
                 cuid  : kernel_uid_t;
                 cgid  : kernel_gid_t;
                 mode  : kernel_mode_t;
             {$if sizeof(kernel_mode_t) < 4}
[114]            __pad1    : array[1..4-sizeof(mode_t)];
             {$endif}
             {$ifdef cpupowerpc}
                     seq       : cuint;
             {$else}
[119]            seq       : cushort;
             {$endif}
                 __pad2    : cushort;
                 __unused1 : culong;
                 __unused2 : culong;
           End;

Beside of this the IDE works well and compiled programs run as expected. But this really annoying. :-$

Antonio.

Array without type?
It's always amazing to find out what fpc supports.

svn trunk can now parse it.

Mattias

I somehow doubt this. It seems more like the condition there is never true and thus the omition was never noticed. At least according to the compiler's code there MUST be a "of" after an array. So it might have been better to investigate why "sizeof(kernel_mode_t) < 4" is evaluated to true by the IDE.

Regards,
Sven

kernel_mode_t is defined in another unit.
The size_of requires parsing like a compiler, that means reading all ppu files first and resolving every type on its way. And it requires implementation details of the compiler.
I guess only the compiler can reliably resolve size_of. Same for declared.

Maybe some heuristics and/or defines can be added to help codetools parsing such $IFs.

Mattias

>>> trying to generate the procedure event code, the unit "ipc" is open and >>> the error "/usr/share/fpcsrc/rtl/unix/ipc.pp(119,9) Error: expected >>> end., but seq found" is displayed in the errors window

This error message looks correct.

>>> {$if sizeof(kernel_mode_t)< 4} >>> [114] __pad1 : array[1..4-sizeof(mode_t)];

This syntax either is illegal or should be added to the parser.

>> svn trunk can now parse it. > I somehow doubt this. It seems more like the condition there is never > true and thus the omition was never noticed.

Right, it looks like a lurking bug to me.

Once the source code is fixed, what doesn't look complicated to me, and doesn't break anything, the problem has gone away. A dedicated "align" directive instead of the explicit alignment had been helpful, too.

The parser also may treat the "of <type>" as optional. This also doesn't look hard to implement, and may be useful in other situations (while source code is edited).

+1

Conditional compilation either requires the *correct* settings, required to evaluate every condition, or silent handling of problems resulting from inproperly included/excluded parts.

Same for declared. Maybe some heuristics and/or defines can be added to help codetools parsing such $IFs.

This IMO would open up a can of worms. Adding the full compiler capabilites to general parsers, including e.g. machine and OS targets, is near impossible. The related compiler units are not usable outside the compiler, and every attempt to create parallel units will end up in a maintenance nightmare. Also much time will be spent, and memory will be occupied, when all used units have to be parsed before the currently active unit.

In the ToPas C-to-Pascal converter I had not only to parse all include files for an specific compiler, but also all effective compiler defines (built-in or configurable) had to be known. This made the proper configuration for a translation very complicated, and the tool unusable for people not very familiar with a specific compiler.

DoDi