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

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

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


From: Joerg Wunsch
Subject: Re: [avr-libc-dev] Progmem types compatibility
Date: Tue, 10 Jan 2012 08:13:02 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

As Dmitry wrote:

> IMHO, there is no bases for such abort (in case of C source and known
> GCC version, i.e. <= 4.6).  It is sufficient to put warning:
>      prog_char s[] = "123";
>      ==> warning: 'prog_char' is deprecated
> and continue building.

If you find a way to put such a warning without bothering *everyone*
(who includes <avr/pgmspace.h>) with the warning, I'm fine with that.
The problem with adding the "deprecated" attribute to the typedef was
that the warning fires as soon as someone includes the header file,
not just when they are about to use it.

I'm afraid GCC lacks a method to delay the warning until the typedef
is actually used.

> IMHO, on the other hand, Avr-libc should not provide prog types with C++
> under no circumstances like __PROG_TYPES_COMPAT__.  As it is known wrong
> (see example at first post), the building must be rejected.

As Johan already told, C and C++ are identical in that respect.  It's
only incidentally the typedefs have been accepted by the C frontend in
the past.  The *only* purpose of __PROG_TYPES_COMPAT__ is to provide
the backwards compatibility to versions < 1.8, and for that reason, I
made the header file generate the very same typedefs in that case as
it used to be in older versions.  If C++ code breaks by that, it was
already broken before, so people should simply not define
__PROG_TYPES_COMPAT__ then.

> May be an example of prog type misbehaviour with C code?

It never "behaved" at all.  Essentially, the entire

typedef prog_foo foo __attribute__((progmem));

was just the same as

typedef prog_foo foo;

(and it even lacked the necessary "const" qualifier)

I could agree to add the latter form (with the "const") as a set of
typedefs when __PROG_TYPES_COMPAT__ is not in effect, so people could
use it for documentation purposes.  PGM_P and PGM_VOID_P are already
defined (and used) that way (because they've been used in many
function prototypes inside the library, and I thought the documentary
effect of using these names was worth keeping it).

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)



reply via email to

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