blady-com / florist Goto Github PK

The default of 'Wait_Indefinitely' is defined as 0. A timeout of 0 in a poll operation returns immediately.

Regards.

POSIX.IO.Generic_Write tries to write repeatedly, but will break if it doesn't get to write the whole amount in the first attempt.

If the first attempt consumes less than half of the data, then Generic_Write sets the size too small in the second attempt, because it subtracts the written amount twice: first on line 484, and then again on line 480 in the next iteration.

If the first attempt consumes more than half of the data but not all of it, then there will be an integer underflow when To_Write < Written on line 480.

Change "To_Write - Written" to just "To_Write" on line 480.

Steps to reproduce:

   alr init --bin issue_1386
   cd issue_1386
   alr with ashell
   alr build

This fails with:

posix-signals.ads:39:06: warning: unnecessary with of ancestor [-gnatwr]

   compilation of posix-signals.adb failed

gprbuild: *** compilation phase failed
error: Command ["gprbuild", "-s", "-j0", "-p", "-P", "/tmp/issue_1386/issue_1386.gpr"] exited with code 4
error: Compilation failed.

The distributed version of the crate should not treat the warnings as errors, since future versions of the compiler can raise new warnings which will impede using the library. The switch should be only used by the maintainer of the library, not for users.

See alire-project/alire#1386 (comment) and following comments.

Thanks for your work.

Regarding the commit on 16 October 2020, "iff" does not look like a typo. See https://en.wiktionary.org/wiki/iff

Hello, is this where Florist is maintained now? In that case I have some bugs to report.

The procedures in POSIX.File_Locking don't properly lock the whole file when Whole_File is True. They look up the file's current size with POSIX.IO.File_Size, and then call fcntl to lock that many bytes. This does not work when another process appends to the file concurrently. Even if the file doesn't grow between the calls to File_Size and fcntl, locking only the file's current size doesn't prevent another process from locking a region past the end and appending to the file.

Quoting the POSIX Programmer's Manual at https://man7.org/linux/man-pages/man3/fcntl.3p.html:

   Locks may start and extend beyond the current end of a file, but
   shall not extend before the beginning of the file. A lock shall
   be set to extend to the largest possible value of the file offset
   for that file by setting l_len to 0. If such a lock also has
   l_start set to 0 and l_whence is set to SEEK_SET, the whole file
   shall be locked.

Replace all three calls to File_Size in posix-file_locking.adb with zero.