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

[Georg-Johann Lay]

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'
perception.

> 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
where.

> 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.

Johann

> 
> Jan
>