[BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument

[BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument

[Denis Zaitsev]

Such an example can't be compiled:


#include <stdio.h>

void x()
{
    printf(__FUNCTION__ "\n");
}


$ gcc printf.c -o fprintf
printf.c: In function `x':
printf.c:5: error: syntax error before string constant


Then, the problem is not printf-specific and is not depend of
<stdio.h>.  The next example gives the same error:


void y(const char *f, ...);
void z()
{
    y(__FUNCTION__ "\n");
}


If some args are present in the ellipsis section (i.e. y(__FUNCTION__
": %s\n", "xxx")), the problem doesn't vanish.  And, if __FILE__ is
used instead of __FUNCTION__, the problem is absent.

Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument

[Richard Guenther]

On 7/25/05, Denis Zaitsev <zzz@anda.ru> wrote:
> Such an example can't be compiled:
> 
> 
> #include <stdio.h>
> 
> void x()
> {
>     printf(__FUNCTION__ "\n");
> }
> 
> 
> $ gcc printf.c -o fprintf
> printf.c: In function `x':
> printf.c:5: error: syntax error before string constant

__FUNCTION__ expands to a variable.  Use

 printf("%s\n", __FUNCTION__);

instead.  Btw, this list is for the development _of_ gcc, not with gcc.
Use gcc-help for that.

Richard.

> 
> Then, the problem is not printf-specific and is not depend of
> <stdio.h>.  The next example gives the same error:
> 
> 
> void y(const char *f, ...);
> void z()
> {
>     y(__FUNCTION__ "\n");
> }
> 
> 
> If some args are present in the ellipsis section (i.e. y(__FUNCTION__
> ": %s\n", "xxx")), the problem doesn't vanish.  And, if __FILE__ is
> used instead of __FUNCTION__, the problem is absent.
>

Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument

[Paolo Carlini]

Richard Guenther wrote:

>Btw, this list is for the development _of_ gcc, not with gcc.
>Use gcc-help for that.
>  
>
By the way, since we have to point out that *so often*, maybe there is
something wrong on our part: I wonder whether changing the names of
those lists would help!?!? I don't know: gcc-development, gcc-users, ...

Paolo.

Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument

[Denis Zaitsev]

On Mon, Jul 25, 2005 at 10:51:23AM +0200, Richard Guenther wrote:
> On 7/25/05, Denis Zaitsev <zzz@anda.ru> wrote:
> > Such an example can't be compiled:
> > 
> > 
> > #include <stdio.h>
> > 
> > void x()
> > {
> >     printf(__FUNCTION__ "\n");
> > }
> > 
> > 
> > $ gcc printf.c -o fprintf
> > printf.c: In function `x':
> > printf.c:5: error: syntax error before string constant
> 
> __FUNCTION__ expands to a variable.  Use
> 
>  printf("%s\n", __FUNCTION__);
> 
> instead.  Btw, this list is for the development _of_ gcc, not with gcc.
> Use gcc-help for that.

Ok, but such a code used to be compiled succesively with gcc for
years.  Then, some change _in_ gcc has occured.  That is why I've
posted to here.

Really, I've met the problem, when I was compiling the X Window System
system.  The sources contain a lot of such an examples.

Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument

[Robert Dewar]

Paolo Carlini wrote:

> By the way, since we have to point out that *so often*, maybe there is
> something wrong on our part: I wonder whether changing the names of
> those lists would help!?!? I don't know: gcc-development, gcc-users, ...

one problem is that people often say something like:

> Btw, this list is for the development _of_ gcc, not with gcc.
>>Use gcc-help for that.

and then go on to answer any way, which somewhat undermines
the msg, and encourages similar questions.

i know that people are trying to be helpful, which
is understandable, but ...

also there is official gcc info suggesting asking this list
for general help if gcc-help does not answer.

Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument

[Paolo Bonzini]

> Ok, but such a code used to be compiled succesively with gcc for
> years.  Then, some change _in_ gcc has occured.  That is why I've
> posted to here.

Yes, it was deprecated in 3.1 (released three years ago) and removed in 
3.3 (released two years ago).

Paolo

Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument

[Denis Zaitsev]

On Mon, Jul 25, 2005 at 11:35:27AM +0200, Paolo Bonzini wrote:
> > Ok, but such a code used to be compiled succesively with gcc for
> > years.  Then, some change _in_ gcc has occured.  That is why I've
> > posted to here.
> 
> Yes, it was deprecated in 3.1 (released three years ago) and removed in 
> 3.3 (released two years ago).

Really, things are not _so_ dramatical...  This is a cite from
extend.tex:


* These identifiers are not preprocessor macros.  In GCC 3.3 and
* earlier, in C only, __FUNCTION__ and __PRETTY_FUNCTION__ were
* treated as string literals; they could be used to initialize char
* arrays, and they could be concatenated with other string literals.
* GCC 3.4 and later treat them as variables, like __func__.


So, the behaviour is changed for 3.4, and is not changed for 3.3.  And
it is STILL not changed - 3.3 is alive - isn't it?

Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument

[Mike Stump]

On Monday, July 25, 2005, at 01:58 AM, Paolo Carlini wrote:
> By the way, since we have to point out that *so often*, maybe there is
> something wrong on our part: I wonder whether changing the names of
> those lists would help!?!? I don't know: gcc-development, gcc-users, 
> ...

No, randomly changing mainline list names will confuse the thousands of 
people that are not confused.  Better to ask them why they thought this 
list was a good idea, and then track down the root of the problem, and 
then fix that.  In the past when I did it, it could be traced to people 
telling them, or to the web site directly.

For example, we could completely remove all references to the gcc 
mailing list from the web site, and invite people after the post a 
single good patch to gcc-help.  :-)  Or, maybe just put it on a page 
called contributing work to gcc.  Most using gcc that just want help 
would not even go to such a page.

Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument

[Gabriel Dos Reis]

Mike Stump <mrs@apple.com> writes:

| On Monday, July 25, 2005, at 01:58 AM, Paolo Carlini wrote:
| > By the way, since we have to point out that *so often*, maybe there is
| > something wrong on our part: I wonder whether changing the names of
| > those lists would help!?!? I don't know: gcc-development, gcc-users,
| > ...
| 
| No, randomly changing mainline list names will confuse the thousands
| of people that are not confused.

I agree changing the list name isn't a proper long term, fix.  After
all, people doing development *with* GCC might also think tha
gcc-development is the proper place ot sned mails instad of gcc-help
:-)

-- Gaby

Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument

[Paolo Carlini]

Gabriel Dos Reis wrote:

>                                                              After
>all, people doing development *with* GCC might also think tha
>gcc-development is the proper place ot sned mails instad of gcc-help
>:-)
>  
>
Yes ;-) On the other hand, some people may believe that gcc-help is the
right list to arrange donations and other activies helping the gcc project
:-)

Paolo.

Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument

[Robert Dewar]

The first step is to have clear documentation.
I sent a message to someone who would posted a question and he replied
by pointing to a clear statement that said tried gcc-help first if you have questions
and if that doesn't work try gcc, and that's what he did!

Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument

[Dale Johannesen]

On Jul 25, 2005, at 1:58 AM, Paolo Carlini wrote:

> Richard Guenther wrote:
>
>> Btw, this list is for the development _of_ gcc, not with gcc.
>> Use gcc-help for that.
>>
>>
> By the way, since we have to point out that *so often*, maybe there is
> something wrong on our part: I wonder whether changing the names of
> those lists would help!?!? I don't know: gcc-development, gcc-users, 
> ...

Perhaps adding something similar to the above to the description
of the gcc list on the web page would help.  What's there seems clear
enough to me, but perhaps a bigger hammer would help other people.