This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: zack's todo list
"Zack Weinberg" <zackw@Stanford.EDU> writes:
> > 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";
> 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.
Exactly. (I was concentrating on the array of characters, so I missed
that one.)
> 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.
Actually, we are dealing with the "no linkage" case here, because
__func__ is a block scope identifier as defined in Section 6.2.1.
> > > 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
If we can agree that this is an example of "linkage", the answer is,
quit obviously: we can't (see footnote 21 in 6.2.2: "There is no
linkage between different identifiers.").
If this is not related to "linkage", we might examine Section 6.7
("Declarations") if it gives some hints, and I think it does:
[#5] A declaration specifies the interpretation and
attributes of a set of identifiers. A definition of an
identifier is a declaration for that identifier that:
-- for an object, causes storage to be reserved for that
object;
[...]
The second declaration (or the first, depending on your view) does not
"cause storage to be reserved for that object", thus violating the
standard. This reasoning may seem a bit weak, but as far as I can
tell, this is the sole place where it is guaranteed that
int a;
int b;
int x = (&a) != (&b);
results in x being assigned the integer 1 (assuming that no
preprocessor macro expansion takes place). So if you don't think that
the standard doesn't mandate two distinct objects with distinct
addresses here, you will most certainly have trouble to prove that
after the declaration
int a, b;
"a" and "b" are identifiers referring to different objects.
> .LC0:
> .string "blah"
> a:
> b:
> .long .LC0
>
> for your modified version.
This is simple string literal merging and is explicitly permitted by
the standard.
6.4.5 String literals
[...]
[#6] It is unspecified whether these arrays are distinct
provided their elements have the appropriate values. If the
program attempts to modify such an array, the behavior is
undefined.
> Failing which, I maintain that there is no
> problem having __func__ share storage with an anonymous string
> constant containing the same string.
Well, I think Section 6.7 doesn't permit this, I'm afraid.
--
Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898