Dmitry schrieb:
Hi!
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.
Johann