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,@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
_______________________________________________
fpc-pascal maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
