«

Consider:

#include <stdio.h>
int main(void)
{
printf("entering function %s\n", __func__);
return 0;
}

Gcc compiles this program without a warning, even
in C89 mode, as in "gcc -Wall -pedantic -std=c89 progname.c".

I expected to see a warning since the identifier __func__ was
introduced in C99. Is there a good reason why the compilation
does not fail in the C89 mode?

--
Rouben Rostamian

On 5/18/2011 10:08, none Rouben Rostamian wrote:
> Consider:
>
> #include<stdio.h>
> int main(void)
> {
> printf("entering function %s\n", __func__);
> return 0;
> }
>
> Gcc compiles this program without a warning, even
> in C89 mode, as in "gcc -Wall -pedantic -std=c89 progname.c".
>
> I expected to see a warning since the identifier __func__ was
> introduced in C99. Is there a good reason why the compilation
> does not fail in the C89 mode?
>

What would _prevent_ GCC from providing this for C89 code?

On 2011-05-18, rouben@shady.(none) (Rouben Rostamian) <rouben@shady> wrote:
> #include <stdio.h>
> int main(void)
> {
> printf("entering function %s\n", __func__);
> return 0;
> }
>
> Gcc compiles this program without a warning, even
> in C89 mode, as in "gcc -Wall -pedantic -std=c89 progname.c".
>
> I expected to see a warning since the identifier __func__ was
> introduced in C99. Is there a good reason why the compilation
> does not fail in the C89 mode?

Your code has undefined behavior. Why should you have any expectations
about what it does?

__func__ is in the implementation's namespace. There is no lack of compliance
with C89 if the implementation happens to define things in its own reserved
namespace...

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Seebs <usenet-> writes:
> On 2011-05-18, rouben@shady.(none) (Rouben Rostamian) <rouben@shady> wrote:
>> #include <stdio.h>
>> int main(void)
>> {
>> printf("entering function %s\n", __func__);
>> return 0;
>> }
>>
>> Gcc compiles this program without a warning, even
>> in C89 mode, as in "gcc -Wall -pedantic -std=c89 progname.c".
>>
>> I expected to see a warning since the identifier __func__ was
>> introduced in C99. Is there a good reason why the compilation
>> does not fail in the C89 mode?
>
> Your code has undefined behavior. Why should you have any expectations
> about what it does?
>
> __func__ is in the implementation's namespace. There is no lack of
> compliance with C89 if the implementation happens to define things in
> its own reserved namespace...

On the other hand, it would certainly be polite for gcc to warn about
this, at least in some mode. The standard imposes no obligation to do
so, but gcc *knows* that __func__ specific to C99, and therefore that
any code that uses it is not portable to non-gcc C90 implementations.

Perhaps there's an option to do so; "-Wall" doesn't actually enable
*all* warnings (but a search of the gcc documentation didn't find such
an option).

(By "gcc knows", of course, I mean that the authors know, and could make
use of that knowedge to make gcc issue a warning.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 2011-05-18, Richard Harter <> wrote:
> Just so. If one is writing code with the hope that it is portable to
> all conforming C90 compilers it would be sporting if compiler writers
> would warn one of their little improvements.

I agree, and I'd prefer that. But I am pretty sure, on thinking about it,
that there is no *required* diagnostic there.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 18 май, 18:08, rouben@shady.(none) (Rouben Rostamian) wrote:
> Consider:
>
> #include <stdio.h>
> int main(void)
> {
> Â* Â* Â* Â* printf("entering function %s\n", __func__);
> Â* Â* Â* Â* return 0;
>
> }
>
> Gcc compiles this program without a warning, even
> in C89 mode, as in "gcc -Wall -pedantic -std=c89 progname.c".
>
> I expected to see a warning since the identifier __func__ was
> introduced in C99. Â*Is there a good reason why the compilation
> does not fail in the C89 mode?
>
> --
> Rouben Rostamian

int main(void) {
__func__;
return 0;
}

$ gcc -S main1.c -Wall -pedantic -std=c89 -o main1.s && cat main1.s
main1.c: In function ‘main’:
main1.c:2: warning: statement with no effect
.file "main1.c"
.text
..globl main
.type main, @function
main:
pushl %ebp
movl %esp, %ebp
movl $0, %eax
popl %ebp
ret
.size main, .-main
.section .rodata
.type __func__.869, @object
.size __func__.869, 5
__func__.869:
.string "main"
.ident "GCC: (GNU) 4.4.4 20100630 (Red Hat 4.4.4-10)"
.section .note.GNU-stack,"",@progbits
$

Dat GCC epic fail IMHO.

>> What would _prevent_ GCC from providing this for C89 code?

Because __func__ in C98 undeclared such as any __ohhelloguys__ thing.

Seebs <usenet-> writes:

> On 2011-05-18, rouben@shady.(none) (Rouben Rostamian) <rouben@shady> wrote:
>> #include <stdio.h>
>> int main(void)
>> {
>> printf("entering function %s\n", __func__);
>> return 0;
>> }
>>
>> Gcc compiles this program without a warning, even
>> in C89 mode, as in "gcc -Wall -pedantic -std=c89 progname.c".
>>
>> I expected to see a warning since the identifier __func__ was
>> introduced in C99. Is there a good reason why the compilation
>> does not fail in the C89 mode?
>
> Your code has undefined behavior. Why should you have any expectations
> about what it does?

Presumably because of the stipulations in 5.1.1.3, ie, at least a
diagnostic must be issued.

> __func__ is in the implementation's namespace. There is no lack of compliance
> with C89 if the implementation happens to define things in its own reserved
> namespace...

The problem is the Standard doesn't say that. The Standard talks
about 'reserved identifiers', not an 'implementation namespace'.
"Reserved" means a program may not declare or define them (modulo
section 7.1.7). The section that specifies which identifiers are
reserved (which is 7.1.3) says that they may be declared or
defined in _header files_ (clearly not relevant for __func__),
but AFAICS nothing otherwise. In the absence of any provision
allowing the implementation itself (as opposed to a header file)
to declare or define reserved identifiers, I don't see why we
should suppose that it's allowed to. And of course that would
mean that '__func__' would cause a syntax error, triggering a
diagnostic.

It's quite plausible that the original intention was to allow
implementations to define reserved identifiers however they like.
I just don't see any text in the Standard that grants such a
right.

On 05/19/2011 05:03 AM, Sorc Chan wrote:
> On 18 май, 18:08, rouben@shady.(none) (Rouben Rostamian) wrote:
>> Consider:
>>
>> #include <stdio.h>
>> int main(void)
>> {
>> printf("entering function %s\n", __func__);
>> return 0;
>>
>> }
>>
>> Gcc compiles this program without a warning, even
>> in C89 mode, as in "gcc -Wall -pedantic -std=c89 progname.c".
>>
>> I expected to see a warning since the identifier __func__ was
>> introduced in C99. Is there a good reason why the compilation
>> does not fail in the C89 mode?
>>
>> --
>> Rouben Rostamian
>
> int main(void) {
> __func__;
> return 0;
> }
>
> $ gcc -S main1.c -Wall -pedantic -std=c89 -o main1.s && cat main1.s
> main1.c: In function ‘main’:
> main1.c:2: warning: statement with no effect
> .file "main1.c"
> .text
> .globl main
> .type main, @function
> main:
> pushl %ebp
> movl %esp, %ebp
> movl $0, %eax
> popl %ebp
> ret
> .size main, .-main
> .section .rodata
> .type __func__.869, @object
> .size __func__.869, 5
> __func__.869:
> .string "main"
> .ident "GCC: (GNU) 4.4.4 20100630 (Red Hat 4.4.4-10)"
> .section .note.GNU-stack,"",@progbits
> $
>
> Dat GCC epic fail IMHO.

It might be an "epic failure" to meet some arbitrary requirement that
you've chosen to impose; but it does not indicate a failure to meet the
requirements imposed by the C89 standard.

>>> What would _prevent_ GCC from providing this for C89 code?
>
> Because __func__ in C98 undeclared such as any __ohhelloguys__ thing.

C89 imposes no such requirement. In fact, the main reason why the C89
standard said that a program using __func__ has undefined behavior is so
an implementation can choose to do anything it wishes to do with
__func__. In particular, the fact that the behavior is undefined gives
the compiler permission to treat __func__ as behaving in precisely the
fashion it's required to behave, according to the C99 standard. It also
gives it permission to treat __func__ as an indication that it should
use your program to generate Funk music.
--
James Kuyper

On 5/19/2011 05:03, Sorc Chan wrote:
> On 18 май, 18:08, rouben@shady.(none) (Rouben Rostamian) wrote:
>> Consider:
>>
>> #include<stdio.h>
>> int main(void)
>> {
>> printf("entering function %s\n", __func__);
>> return 0;
>>
>> }
>>
>> Gcc compiles this program without a warning, even
>> in C89 mode, as in "gcc -Wall -pedantic -std=c89 progname.c".
>>
>> I expected to see a warning since the identifier __func__ was
>> introduced in C99. Is there a good reason why the compilation
>> does not fail in the C89 mode?
>
> int main(void) {
> __func__;
> return 0;
> }
>
> $ gcc -S main1.c -Wall -pedantic -std=c89 -o main1.s&& cat main1.s
> main1.c: In function ‘main’:
> main1.c:2: warning: statement with no effect
> .file "main1.c"
> .text
> .globl main
> .type main, @function
> main:
> pushl %ebp
> movl %esp, %ebp
> movl $0, %eax
> popl %ebp
> ret
> .size main, .-main
> .section .rodata
> .type __func__.869, @object
> .size __func__.869, 5
> __func__.869:
> .string "main"
> .ident "GCC: (GNU) 4.4.4 20100630 (Red Hat 4.4.4-10)"
> .section .note.GNU-stack,"",@progbits
> $
>
> Dat GCC epic fail IMHO.
>
>>> What would _prevent_ GCC from providing this for C89 code?
>
> Because __func__ in C98 undeclared such as any __ohhelloguys__ thing.

Is it a documented extension? (See "COMPLIANCE" section.)

Is it incompatible with C89? (See 'man gcc' "-ansi" section and "std="
section.)

Here's some potentially relevant GCC documentation:


http://gcc.gnu.org/onlinedocs/gcc-4....Function-Names

Tim Rentsch <> writes:
> Seebs <usenet-> writes:
[...]
>> __func__ is in the implementation's namespace. There is no lack of
>> compliance with C89 if the implementation happens to define things in
>> its own reserved namespace...
>
> The problem is the Standard doesn't say that. The Standard talks
> about 'reserved identifiers', not an 'implementation namespace'.
> "Reserved" means a program may not declare or define them (modulo
> section 7.1.7). The section that specifies which identifiers are
> reserved (which is 7.1.3) says that they may be declared or
> defined in _header files_ (clearly not relevant for __func__),
> but AFAICS nothing otherwise. In the absence of any provision
> allowing the implementation itself (as opposed to a header file)
> to declare or define reserved identifiers, I don't see why we
> should suppose that it's allowed to. And of course that would
> mean that '__func__' would cause a syntax error, triggering a
> diagnostic.
>
> It's quite plausible that the original intention was to allow
> implementations to define reserved identifiers however they like.
> I just don't see any text in the Standard that grants such a
> right.

Quibble: It would be a constraint violation, not a syntax error, but
that doesn't affect the argument.

C99 5.1.1.3 explicitly states that violations of syntax rules and
constraints must be diagnosed even in the presence of undefined
behavior. C90 5.1.1.3 does not, and the possible consequences of
undefined behavior include "behaving during translation or program
execution in a documented manner characteristic of the environment
(with or without the issuance of a diagnostic message)" (C90 3.16).

But we're still left with the question of whether a conforming C99
implementation may predefine __foo__ (not in any header). Like you,
I'd say that the intended answer s yes, but I can't prove it from
the standard.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"