You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Attempting to use GNATCOLL.Mmap to interact with character devices ends up with the program always receiving a zero-length region pointing to Empty_String'Address, rather than any actual mapping, since character devices (such as those under /dev) are reported as being zero in length. GNATCOLL clamps mapping lengths and offsets to the reported file bounds, and attempts to sidestep cases in which mmap would return either failure or a NULL mapping, but I figure it might be simpler to just attempt the map straight-away and then react to failure as appropriate.
Consider the following:
withGNATCOLL.Mmap; use GNATCOLL.Mmap;
withAda.Text_IO; use Ada.Text_IO;
withSystem;
procedureGNATCOLL_Bugis
File : Mapped_File := Open_Write ("/dev/zero");
Region : Mapped_Region := Read (File, Length => 128, Mutable => True);
Address : System.Address := Data_Address (Region);
type My_Data isarray (0 .. 127) of Character
with Component_Size => 8;
Data : My_Data
with Address => Address;
begin
Put_Line (Data_Size (Region)'Image);
Data (64) := 'Y'; -- oops!endGNATCOLL_Bug;
One might expect Data to point to a 128-byte region of memory mapped from the device at /dev/zero (we can pretend it is something more useful), and that writing into it would replicate the write to the device itself, as it would have been had we been using raw mmap. Instead, Data points to an arbitrary chunk of read-only memory starting at Empty_String'Address, and writing to it would get a STORAGE_ERROR raised, or worse.
The text was updated successfully, but these errors were encountered:
Attempting to use GNATCOLL.Mmap to interact with character devices ends up with the program always receiving a zero-length region pointing to
Empty_String'Address
, rather than any actual mapping, since character devices (such as those under/dev
) are reported as being zero in length. GNATCOLL clamps mapping lengths and offsets to the reported file bounds, and attempts to sidestep cases in which mmap would return either failure or a NULL mapping, but I figure it might be simpler to just attempt the map straight-away and then react to failure as appropriate.Consider the following:
One might expect
Data
to point to a 128-byte region of memory mapped from the device at/dev/zero
(we can pretend it is something more useful), and that writing into it would replicate the write to the device itself, as it would have been had we been using rawmmap
. Instead,Data
points to an arbitrary chunk of read-only memory starting atEmpty_String'Address
, and writing to it would get aSTORAGE_ERROR
raised, or worse.The text was updated successfully, but these errors were encountered: