On 07/01/2012 14:23, Georg-Johann Lay wrote:
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
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?
mvh.,
David
_______________________________________________
AVR-libc-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
