Graham Davies wrote:
David Brown wrote:
... you are ... protecting the code sequence, not the data itself -
the data is indirectly protected by always using
protected code sequences to access it.
I think this is just a point-of-view thing. I could be wrong, but I
think the prevalent point of view is that it is the data that needs to
be protected. Any means to do that would be acceptable. It seems
strange to talk about protecting the code sequence. Making sure that
the code executes in sequence and without interruption is just a means
to the primary end of protecting the data.
Graham.
In some cases, it makes sense to think about protecting the data - in
particular, you often want to make sure that no part of the program can
access the data in an inconsistent state. In that sense, you protect
code sequences as a way to protect the data. But you also want
sequences of code that access different data objects rather than
directly protecting the data.
Ultimately, code is merely something that manipulates data, and data is
merely intermediate results of code, so it is, as you say, a
point-of-view thing. My point was just that it is often most practical
to think in terms of protecting code sequences rather than data - you
can't view all cases in terms of protecting data until you abstract to
the level of all the data in the system being part of a single large
object, and all the code in the system being methods manipulating that
data object.
At least, that's how I view it. Perhaps if I were a C++ programmer
rather than a C programmer, I'd view it in a more data-centric way.
mvh.,
David
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list