[Top][All Lists]

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

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

From: Georg-Johann Lay
Subject: Re: [avr-libc-dev] Progmem types compatibility
Date: Sat, 07 Jan 2012 14:23:38 +0100
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

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.


reply via email to

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