From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,5b518364bbeba851 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews1.google.com!k26g2000oda.googlegroups.com!not-for-mail From: "Mattias Lindblad" Newsgroups: comp.lang.ada Subject: Re: POSIX_Generic_Shared_Memory Date: 29 Sep 2004 05:09:39 -0700 Organization: http://groups.google.com Message-ID: <1096459779.696500.183000@k26g2000oda.googlegroups.com> References: <1095700990.407634.230970@k26g2000oda.googlegroups.com> NNTP-Posting-Host: 136.163.203.4 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1096459780 9739 127.0.0.1 (29 Sep 2004 12:09:40 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 29 Sep 2004 12:09:40 +0000 (UTC) User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: k26g2000oda.googlegroups.com; posting-host=136.163.203.4; posting-account=G_yeBA0AAACtPq9DidGEMkcZzYN7f0BR Xref: g2news1.google.com comp.lang.ada:4375 Date: 2004-09-29T05:09:39-07:00 List-Id: > Try to look in the file posix-generic_shared_memory.adb for the two > functions you use and inspect that they contain the following statement: > > if Protection = POSIX.Memory_Mapping.Allow_Write then > Mode := POSIX.IO.Read_Write; > else Mode := POSIX.IO.Read_Only; > end if; Yes, this is what my versions look like. And yes, I agree that we shouldn't really blame Florist for this. I would probably interpret the standard in the same way. Unfortunately, this leaves these functions practically unusable in my opinion. However, I think it would be possible to change the implementation to a usable version and still be compliant with the standard. The standard does not mention anything about the protection parameter that is sent to the intrinsic calls to Map_Memory. This means that an implementation could set the protection options in the Map_Memory call to (Allow_Read + Allow_Write) in the case where the received protection parameter is Allow_Write. The only downside I can think of is that you wouldn't be able to create a write-only shared memory partition. In my opinion, this is definitely less of a problem than the current situation where you cannot create a read-write partition. But ultimately, a better solution would be to change the text in the standard to read something like "If Allow_Write is a subset of Protection, Mode is Read_Write; otherwise Mode is Read_Only." This would solve the problem in a better way. The protection options could then be passed straight through to Map_Memory, which I think is the most logical way. And I don't think a change of implementations to support this would break any existing code. //Mattias