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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!gegeweb.org!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Comments requested for a couple of Ada-Comments submissions Date: Thu, 10 Jul 2014 23:26:06 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1405052768 18580 69.95.181.76 (11 Jul 2014 04:26:08 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 11 Jul 2014 04:26:08 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:20861 Date: 2014-07-10T23:26:06-05:00 List-Id: "Simon Clubley" wrote in message news:lpn9ic$acs$1@dont-email.me... ... > There are conflicting opinions in comp.lang.ada. The words "as a whole" > in C.6(15) were used to justify the position that access to this single > bitfield is not required to be in units of the record size which on the > surface seemed reasonable. > > However, other opinions are that C.6(15) does apply when accessing this > single bitfield. > > Which opinion is correct ? I suspect that we're going to end up confirming what compilers do, rather than what they ought to do. That's because of the possibility of breaking existing working code if one enforced additional legality rules. Which means an interesting question is the actual problem. If you have a device that can *only* be accessed by a 32-bit operation, any other access is wrong and it would be best if the compiler would report such accesses. (When I asked about it, I was told that GNAT doesn't even make a warning.) Requiring the compiler to do something that simply will not work is not helpful to anyone and isn't very Ada-like. One possibility (assuming that piece-meal updating has to be allowed) would be to have a Restriction that could be applied to an atomic object, such that only reads and updates as a whole would be allowed. Reads and updates of parts would then be rejected. (Of course, such a restriction would only have an effect on objects of composite types.) I think you ought to add something on this line to your submission; the critical point (the problem, as always) is buried that the very end of your question. Here, the problem is that accessing a device register piecemeal does not work, and there should be a way in Ada to prevent such accesses. If the existing rules don't have that effect, then we need some mechanism to ensure proper access. So, I'd suggest putting the problem first (as in an AI), the question about the existing rules second, and then (optionally) a possible solution if the existing behavior is confirmed. Randy.