Georg-Johann Lay wrote:
> Ulrich Weigand schrieb:
> > It's not a restriction so much, it's simply that TR 18037 does not say
> > anything
> > about string literals at all, so they keep working as they do in standard C.
>
> Take the following bit more elaborate example where you want to describe
> a menu:
[snip]
> Thus you have no alternative and have to use menu1_t:
>
> const char __as STR_YES[] = "Yes";
> const char __as STR_NO[] = "No";
> const char __as STR_DUNNO[] = "Don't really know and will decide later";
>
> const menu1_t menu3 =
> {
> 1,
> {
> STR_YES,
> STR_NO,
> STR_DUNNO
> }
> };
>
> With some menues you soon end up with dozens of unnecessary variables
> just because TR 18037 has a blank area on it's map.
I agree that this is best approach. You can even avoid the unnecessary
variables by using a compound literal with AS-qualified char array type,
and initialize the AS pointer to its address, like e.g. so:
const __as char *pallo = (const __as char []){"pallo"};
That's still a bit awkward, but that could be hidden via a macro ...
> This means that a line like
> const __as char * pallo = "pallo";
> can be very useful and that there is exactly one meaning that makes
> sense: put "pallo" in __as because otherwise you won't be able to
> reference that string.
That's not really true: on some targets, the generic address space
will indeed be a subset of __as, so you *can* assign the address of
a string literal in the generic space to an __as pointer variable.
Even on the SPU, this works when the assignment is not done at
initialization time:
const __ea char *p;
int test (void)
{
p = "test";
}
This will generate code to convert the address of the literal "test"
in the generic address space into a __ea address and assign it to
the __ea pointer.
> Even more preferred would be to assign the only sensible meaning
> (provided a target allows it), which should be legal as that extension
> is implementation defined, anyway.
What is implementation defined is whether conversion of a pointer
to a different address space is allowed at *initialization* time
or not.
What is *not* implementation defined is that string literals are
always in the generic address space -- that's simply a requirement
of the standard.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
