comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Comments requested for a couple of Ada-Comments submissions
Date: Thu, 10 Jul 2014 23:26:06 -0500
Date: 2014-07-10T23:26:06-05:00	[thread overview]
Message-ID: <lpnp0v$i4k$1@loke.gir.dk> (raw)
In-Reply-To: lpn9ic$acs$1@dont-email.me

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> 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.


  parent reply	other threads:[~2014-07-11  4:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-11  0:02 Comments requested for a couple of Ada-Comments submissions Simon Clubley
2014-07-11  0:30 ` Jeffrey Carter
2014-07-11  4:16   ` Randy Brukardt
2014-07-11 16:04     ` Niklas Holsti
2014-07-11 16:24       ` Dan'l Miller
2014-07-11 20:02       ` Simon Clubley
2014-07-12  5:52         ` Niklas Holsti
2014-07-11  4:26 ` Randy Brukardt [this message]
2014-07-11  7:05   ` Simon Clubley
2014-07-11  4:56 ` Shark8
2014-07-11 15:35   ` Adam Beneschan
2014-07-11 17:26     ` Niklas Holsti
2014-07-11 17:55       ` Adam Beneschan
2014-07-11 18:00         ` Simon Wright
2014-07-11 19:07           ` Georg Bauhaus
2014-07-11 19:10           ` Dmitry A. Kazakov
2014-07-11 19:16             ` Niklas Holsti
2014-07-11 19:35               ` Dmitry A. Kazakov
2014-07-11 21:24             ` Randy Brukardt
2014-07-11 21:46               ` Shark8
2014-07-11 19:30       ` Simon Clubley
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox