This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Proposal: readable and writable attributes on variables

On 08/31/2016 04:56 AM, Jens Bauer wrote:
Hi Martin (and everyone else on the gcc list).

I appreciate your input and kind reply to my proposal. :)

On Tue, 30 Aug 2016 20:44:35 -0600, Martin Sebor wrote:
This sounds reasonable and useful to me but to be fully integrated
into the language, attribute not_readable would need to be elevated
to the status of a type qualifier analogous to const.  Otherwise it
would (likely, if applied as most other attributes) be lost during
conversions such as in

   __attribute__ ((not_readable)) int write_only;
   int *preadwrite = &write_only;

Would it not be possible to bring a warning in such cases ?
-or would that actually require a kludge ?

I would expect it to be easier to issue a warning than to add support
for a whole new type qualifier to the two GCC front ends (C and C++).
The latter, of course, has the advantage of a more robust solution.

If it's not possible (or if it's too complicated to bring a warning or error), then I would still find it valuable to have __attribute__((not_writable)) and __attribute__((not_readable)).

They're intended to be used in structures, which in the CMSIS case would be something like this:

#define __I		volatile __attribute__((not_writable))
#define __O		volatile __attribute__((not_readable))
#define __IO	volatile
#define __NA	__attribute__((not_readable,not_writable)) /* not available or no access */

typedef struct {
   __IO uint32_t		SR
   union {
     __I  uint32_t	IDR;			/* input data register */
     __O  uint32_t	ODR;			/* output data register */
   __NA uint32_t		reserved[2];	/*  */

This could be implemented via unnamed bit-fields:

  uint32_t: 32;
  uint32_t: 32;

   /* .. more registers here .. */

USART3->ODR = byteToSend;
receivedByte = USART3->IDR;

I'm not sure I understand the purpose of using the union here but
that's probably not important for your proposal.

Normally, __I, __O and __IO are defined as follows in the CMSIS include files:
#ifdef __cplusplus
   #define __I   volatile          /*!< Defines 'read only' permissions */
   #define __I   volatile const    /*!< Defines 'read only' permissions */
#define __O     volatile          /*!< Defines 'write only' permissions */
#define __IO    volatile          /*!< Defines 'read / write' permissions */

-That means for C++, __I does not work entirely as intended; it was probably done this way due to RTTI.
I believe that in this case an attribute would not have this problem ?

I can't imagine what impact RTTI might have on this. I'd expect
"__attribute__((not_writable))" to map to "const" with no need for
the attribute.

__O can not prohibit reading.
Some hardware registers react upon 'access'; eg. if read, it becomes zero, if written, only the set bits are changed.
__O currently cannot prevent reading such registers.

Understood.  I think a write-only attribute or type qualifier would
make sense.  Until/unless it's implemented I would recommend to work
around its absence by hiding access to the registers behind a read-
only and write-only functional API.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]