[Bug c/20258] error generated for storage class specified for function parameter

["schlie at comcast dot net" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From schlie at comcast dot net  2005-03-01 21:41 -------
Subject: Re:  error generated for storage class specified for
 function parameter

> --- Additional Comments From joseph at codesourcery dot com  2005-03-01
> Subject: error generated for storage class specified for function parameter
>              
>> On Tue, 1 Mar 2005, schlie at comcast dot net wrote:
>> - unless I misunderstand the question, the only way a pointer itself would
>>   be stored in ROM were if it were itself a static const value, and in turn
>>   would itself need to be referenced by a (static const *), where once
>>   referenced, (i.e. the pointer's value is now in a non-static variable) so
>>   it itself never be further qualified (I think)?
> 
> Just as you can have "char *" and "char *const" and "const char *" and
> "const char *const", you can have "ROM pointer to ROM" and "ROM pointer to
> RAM" and "RAM pointer to ROM" and "RAM pointer to RAM", and similarly with
> more levels of indirection.
> 
> If you want to handle address spaces properly, look at DTR 18037 (or the
> final TR once the subclause numbering has been agreed with ISO).  There is
> no bug here, although making GCC handle multiple address spaces properly
> in the manner described in DTR 18037 might be useful for some targets.

Thank you for the reference, and do also agree there's no "bug" in the
present implementation. However do observe that although the present use of
of a storage-class specifier in the context of a parameter type-qualifier is
not supported by the present standard; it may be worthy of consideration as
a sensible optionally enabled extension; as the use of the combination
"static const" in this context seems fully consistent with the specification
of an otherwise explicit ROM address-space-qualifier, as it is just this
combination which is typically used to identify values which may be stored
as ROM'ed data.

Therefore seems reasonable to consider compatibly optionally extending the
use of "static const" as an implied read-only address-space qualifier, as it
would not introduce any ambiguities because it's present use in this context
is not supported (and seems easier to initially enable, than DTR18037 is).

Might you be willing to consider a patch enabling this option use?

---

As an aside, with respect to the various permutations of static const *,
etc. It seems that by simply designating the combination "static const" as
an optional legal type qualifier within contexts not otherwise supporting
the designation of a storage-class specifier, GCC can be relatively easily
enabled to support an implied primitive ROM address-space which is distinct
from the remaining default address space (being implied by everything not
"static const").

For example, with respect to the optional extension of "static const" as
a function parameter's qualifier, since parameters are passed in RAM, ROM
(i.e. "static const") values may only be passed by reference by definition,
which eliminates I believe much of it's potential complexity. For example:

int foo (int * static const x);

Is physically impossible, as parameters are implied to be variable,
therefore must be passed in RAM, therefore must not in ROM. However as you
note, with the exception of this restriction, any subsequent hierarchy of
qualifiers would be valid, although some of likely limited practical use.




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258