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.
next prev 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