[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 

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
.  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

[Denis Zaitsev]

On Mon, Jul 25, 2005 at 10:51:23AM +0200, Richard Guenther wrote:
> On 7/25/05, Denis Zaitsev <[EMAIL PROTECTED]> wrote:
> > Such an example can't be compiled:
> > 
> > 
> > #include 
> > 
> > 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

[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?

gcc-3.4.4-20050211: maybe a danger behaviour

[Denis Zaitsev]

Consider the following example:


enum w {
//c=-1,
a,
b
};
whattodo (
char option
) {
static
struct todo {
enum w what;
char option;
} todos[]= {
{a,'a'},
{b,'b'},
{-1}
};
struct todo *p= todos;
do if (
(option && !option)
) break;
while ((++p)->what >= 0);
return p->what;
}


Compiling with -O[>0] and -Wall for x86 we have that code for
whattodo:


whattodo:
.L2:
jmp .L2


a) Formally, the code is correct.  As p->what can never be < 0
according to its type.

b) GCC _silently_ allows the {-1} initialization for that type, even
with -Wall.

Uncommenting the c= -1 member of enum, or explicit casting p->what to
int solves the problem, of course.  But maybe some warning would be
appropriate in such a situation?  It takes some time for me to
recognize what leads me to that cool .L2: jmp .L2 from seemengly
harmless C code...  Or maybe I don't know some healthy compiler
option?