Hi Alex,
Thank you for looking after this.
According to the man page on macOS, poll returns:
[EINVAL] The nfds argument is greater than OPEN_MAX or the
timeout argument is less than -1.
The check at compile time is not triggered on macOS, the following program
prints “false”:
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char*argv[])
{
#if (int)-1 == 0xFFFFFFFF
printf("true");
#else
printf("false");
#endif
return 0;
}
Regards,
Andras Pahi
> On 2021. Apr 17., at 11:42, Alexander Burger <a...@software-lab.de> wrote:
>
> Hi Andras,
>
>> It is very strange indeed, on macOS Mojave gPoll() receives sometimes timeout
>> values which when casted to (int) results in values less than -1 (eg. -3).
>> This results in EINVAL errors in poll().
>
> The EINVAL is indeed strange. According to the man page any negative timout
> should result in an infinite wait.
>
>
>> I have inserted a code snippet which truncates the timeout to -1 then I can
>> get
>> to the login page in the demo app.
>
> This should not be necessary since PicoLip 21.4.15. It checks at compile time
> whether it is a system with 32-bit int's, and then passes -1 for larger
> numbers:
>
> #if (int)-1 == 0xFFFFFFFF
> else if (timeout > 2147483647) // Fit into 32 bits (max 24 days)
> timeout = -1;
> #endif
>
> I cannot test it here. Can you verify that it works?
>
>
>> Entering eg. “ben”, “ben” results in dropping the connection. The task
>> handling the connection
>> is forked, as I see in the process list.
>
> Hmm, so the above is not enough. There must be some other problem, perhaps
> also
> related to 32-bit integers.
>
> ☺/ A!ex
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
