avr-libc-dev
[Top][All Lists]
Advanced

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

[avr-libc-dev] Progmem types compatibility


From: Dmitry
Subject: [avr-libc-dev] Progmem types compatibility
Date: Sat, 07 Jan 2012 14:41:54 +1000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17pre) Gecko/20110415 Thunderbird/3.1.10pre

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 };
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

C source:
    typedef char prog_char __attribute__((progmem));
    const prog_char s[10] = { 0 };
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:  OK
4.7:    OK

C++ source:
    typedef char prog_char __attribute__((progmem));
    prog_char s[10] = { 0 };
3.3.6:  OK
3.4.6:  OK
4.0.4:  OK
4.1.2:  OK
4.2.4:  OK
4.3.6:  Bad allocation
4.4.6:  Bad allocation
4.5.3:  Bad allocation
4.6.2:  Bad allocation
4.7:    Bad allocation

C++ source:
    typedef char prog_char __attribute__((progmem));
    const prog_char s[10] = { 0 };
3.3.6:  OK
3.4.6:  OK
4.0.4:  Bad allocation
4.1.2:  Bad allocation
4.2.4:  Bad allocation
4.3.6:  Bad allocation
4.4.6:  Bad allocation
4.5.3:  Bad allocation
4.6.2:  Bad allocation
4.7:    OK

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


What is worse:
-------------

1. C project, now changes.  Now the compilation is aborted with indistinct
message:
    error: expected '=', ',', ';', 'asm' or '__attribute__' before 's'

2. After defining __PROG_TYPES_COMPAT__ the user can not avoid a
flow of warning spam.

3. C++ project, after defining __PROG_TYPES_COMPAT__: the building is OK
with unpredictable result.

4. Illogical PGM_P (and PGM_VOID_P) usage:
    without __PROG_TYPES_COMPAT__ --> OK,
    after defining __PROG_TYPES_COMPAT__ --> a flow of warnings.


A suggestion is:
---------------

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

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.

4. Define PGM_P/PGM_VOID_P as 'const char/void *' (i.e. without prog
types) in all cases, with note in documentation (this note is not ready yet).

Regards,
Dmitry.

Attachment: pgmspace.h
Description: Text document


reply via email to

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