[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] Progmem types compatibility

From: David Brown
Subject: Re: [avr-libc-dev] Progmem types compatibility
Date: Mon, 09 Jan 2012 09:08:32 +0100
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0

On 07/01/2012 14:23, Georg-Johann Lay wrote:
Dmitry schrieb:

There are a bit of worses with deprecation of prog types in 1.8.0.

First, look the possibility of usage progmem attribute with a typedef
depending on GCC version and source language:

C source:
typedef char prog_char __attribute__((progmem));
prog_char s[10] = { 0 };

Attribute progemem is documented for declarations only.

Using progmem on types is an undocumented feature with undefined
behaviour, so you use it at your own risk, durprise and fun.

3.3.6: OK
3.4.6: OK
4.0.4: OK
4.1.2: OK
4.2.4: OK
4.3.6: OK
4.4.6: OK
4.5.3: OK
4.6.2: Compile error
4.7: Compile error

Yes, the compiler will nag you to only put constant data into flash.
This is same with as with new address space feature in avr-gcc 4.7.0.

So, the prog_char works with C programs and does not work
(unpredictable) with C++ ones.

No it works neither reliably in C nor in C++, see above.
It does not work per design, it works per accident.

A suggestion is:

1. Not to define prog types with C++.

Not define progmem-tyes at all, because avr-gcc does not support them.

2. Define prog types with C source for known GCC versions, with
deprecated attribute. Note, that an inclusion <avr/pgmspace.h> does not
generate a warning, it would be in case of real usage such type.

3. If __PROG_TYPES_COMPAT__ is defined and language is C, define prog
type regardless of GCC version and without deprecated attribute.

IMO, the longer the progmem-in-types stuff is kept and floating around,
the more trouble users will have and the more developer resources will
be occupien without need. At some point user must decide if he wants
clean code or to use undefined features, to use old tools or to switch
to new tools.

progmem-in-types works per accident in avr-gcc; the support in avr-gcc
is the same as in avr-g++. The difference between C and C++ is just an
artifact of how the different front ends works, but there is no
difference in the AVR backend of GCC.

Actually it was possible to throw proper error message on
progmem-in-type or to properly support the feature. The dicision was,
however, to do nothing about it and leave the implementation in the
state it is, i.e. might work or might not work.


Being able to attach the "progmem" attribute to the type is a useful feature - or it would be, if it were safe to use. The main reason, as I see it, is the same with all type information - it helps improve the safety, static (compile-time) error checking, and self-documenting aspects of code. It's a bit like attaching "const" or "volatile" to the type declaration. This would apply even if the declaration of variables still need "const PROGMEM" - attaching "progmem" to the type helps the compiler spot mistakes such as missing "const".

However, since we are now moving to a different system for flash data in gcc 4.7 (using address spaces), I doubt if there is any point in changing today's system - the compiler (or the library) gives deprecated warnings when use of "progmem" on types is unreliable. But will it be safe to use them with the new address space system? And if it is not safe, will there be a unambiguous error message if the user tries this?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]