zack's todo list

[Zack Weinberg]

On Wed, Nov 15, 2000 at 10:49:18AM +0100, Florian Weimer wrote:
> "Zack Weinberg" <zackw@Stanford.EDU> writes:
> 
> > Now where is it written that this requires that __func__ be separate
> > from other objects?  
> 
> The declaration
> 
>         static const char __func__[] = "function-name";
> 
> specifically requests that a new object is created, in contrast to:
> 
>         static const char * const __func__ = "function-name";

Hm, not as I read the standard.  Both of them request a new object be
created.  The first produces assembly like so:

__func__:
	.string "function-name"

the second:

.LC0:
	.string "function-name"
__func__:
	.long .LC0

(type/size/section annotations omitted for brevity)

These are not the same thing.  The object created in the first case is
the string itself; in the second, it's a pointer to the string.  They
are functionally equivalent in many, but not all, contexts.

Now the question we're discussing is whether or not two read-only
named objects with internal linkage are allowed to have the same
address in memory, if their contents are identical.  This is
independent of whether or not 'a new object is created', and also
independent of the form of declaration.

> > static const char a[] = "blah";
> > static const char b[] = "blah";
> > 
> > - must a and b be different?  The embedded people would surely like
> >   them to be merged.
> 
> If somebody wants to share the values, one should write:
> 
> static const char * const a = "blah";
> static const char * const b = "blah";

I want to see chapter and verse that says we can't emit

a:
b:
	.string "blah"

for my original C fragment, and

.LC0:
	.string "blah"
a:
b:
	.long .LC0

for your modified version.  Failing which, I maintain that there is no
problem having __func__ share storage with an anonymous string
constant containing the same string.

zw