[fpc-pascal] POpen en PClose

Adriaan van Os adriaan at adriaan.biz
Mon Jul 20 19:56:16 CEST 2026



On 20/07/2026 16:19, Marco van de Voort via fpc-pascal wrote:
>
> Op 20-7-2026 om 15:13 schreef Adriaan van Os via fpc-pascal:
>>>
>>> So popen/pclose are a more high level (FILE * using) part of libc, 
>>> while we tend to only use the basis.
>>
>> Ah, so that means that I couldn't just call naively into libc popen 
>> with FileRec.Handle ?
>>
> Indeed.   And FILE* is opague and thus target specific,  it would mean 
> another structure to maintain, and to somehow to determine for a new 
> *nix target. STAT and STATFS already give us grief enough.

Right. So now I am calling PClose and it will hang. Why ? Well, PClose 
calls WaitProcess in unx.pp, which in turn calls fpWaitPid in a loop, 
which returns (on Darwin) 0 for a process that has died ....

   repeat
     r:=fpWaitPid(Pid, at s,0);
     if (r=-1) and (fpgeterrno=ESysEIntr) Then
       r:=0;
   until (r<>0);

In general, I find such a loop, that depends on result codes, quite 
risky. The POSIX standard says here 
<https://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html>

   "If/wait/() or/waitpid/() return because the status of a child 
process is available, these functions shall return a value equal to the 
process ID of the child process. In this case, if the value of the 
argument/stat_loc/is not a null pointer, information shall be stored in 
the location pointed to by/stat_loc/. The value stored at the location 
pointed to by/stat_loc/shall be 0 if and only if the status returned is 
from a terminated child process that terminated by one of the following 
means:"

Regards,

Adriaan van Os
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20260720/1962e651/attachment-0001.htm>


More information about the fpc-pascal mailing list