[Top][All Lists]

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

Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal

From: Georg-Johann Lay
Subject: Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal
Date: Wed, 28 Sep 2011 09:43:30 +0200
User-agent: Thunderbird (X11/20100302)

Jan Waclawek schrieb:
>> prog_char as a macro is dreaded.
>> const prog_char * const p = NULL;
>> puts p in progmem so it's broken by design. With that users will be taken
>> for a ride.
> But it's not the macro which is broken, it's the attribute!
> The manual explains in
> http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Attribute-Syntax.html#Attribute-Syntax
> in lenght the expected semantics of attributes in pointer declarators, and
> that they behave in the same way as qualifiers (which is the logical,
> expected way). Although it also says that this is not always implemented,
> I'd expect it to be implemented in such prime example for a qualifier-like
> attribute.
> Nothing prevents the user to write down the "raw" version: const char
> __attribute__((__progmem__)) * const p = NULL; just to get the same
> unexpected behaviour, broken code being generated quietly.

If user writes it down that way, it's the fault of the user.
But if an official header supplies "prog_char" it's supposed to work no matter
what its innards are, and it is supposed to work.

It's no difference in the functionality, it's just a difference in users'

> So I suggest to fix this as first in avr-gcc.

Didn't look at it in detail, but I saw similar things on other targets. So
maybe it's inherent to attribute and the documentation is too optimistic and
promising. You just see "there is an attribute somewhere in the decl" but not

> One more thing: if you think the progmem-in-typedef stuff is so badly broken
> that it works only by accident, may result in unexpected behaviour, and even
> if appears to work now may change in the future - why don't you then suggest
> *complete removal* of those symbols from pgmspace.h, rather than just their
> depreciation?

Deprecation comes with a proper message whilst just removing the stuff gives an
error and the impression that something in the headers is broken, causing flood
of bug reports.

I also asked the avr-gcc maintainers about that issue and if

- error on progmem in typedef or
- deprecate it aling with appropriate message or
- fully support it

the answer was

- don't do anything

So the best avr-libc can do IMHO is to keep its own sources clean.


> Jan

reply via email to

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