Re: Proposal: readable and writable attributes on variables

[Jens Bauer <jens-lists at gpio dot dk>]

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 ?


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];	/*  */
  /* .. more registers here .. */
};

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


Normally, __I, __O and __IO are defined as follows in the CMSIS include files:
#ifdef __cplusplus
  #define __I   volatile          /*!< Defines 'read only' permissions */
#else
  #define __I   volatile const    /*!< Defines 'read only' permissions */
#endif
#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 ?
__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.


I'll wait for a few days and see if there are someone who can find flaws with the proposal.
Using attribute would be my best suggestion, because it would not change the C language.
Also, if anyone have improvements to this proposal, please speak up (I'm interested in the best solution). ;)


Love
Jens