[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

The variable __func__ in C89 in gcc

rouben

5/18/2011 2:09:00 PM

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
27 Answers

Shao Miller

5/18/2011 2:14:00 PM

0

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?

Seebs

5/18/2011 4:04:00 PM

0

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-nospam@seebs.net
http://www.seeb... <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/...(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Keith Thompson

5/18/2011 5:32:00 PM

0

Seebs <usenet-nospam@seebs.net> 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-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

cri

5/18/2011 7:40:00 PM

0

On Wed, 18 May 2011 10:32:09 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>Seebs <usenet-nospam@seebs.net> 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.)

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.

Seebs

5/18/2011 7:46:00 PM

0

On 2011-05-18, Richard Harter <cri@tiac.net> 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-nospam@seebs.net
http://www.seeb... <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/...(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

William Ahern

5/19/2011 2:28:00 AM

0

Keith Thompson <kst-u@mib.org> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
<snip>
> > __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.)

According to my local man page GCC won't warn about `__' prefixed
identifers, even in -pedantic mode. GCC supports prefixing of non-standard
features even when in strict or pedantic mode. For example, __restrict__ or
__typeof__(). I'm unsure if the suffix is required, but using a prefix and
suffix is conventional.

Failing to warn about __func__ might be an unintended consequence of the way
this extension feature is implemented.

Sorc Chan

5/19/2011 9:04:00 AM

0

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.

Tim Rentsch

5/19/2011 10:04:00 AM

0

Seebs <usenet-nospam@seebs.net> 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.

James Kuyper

5/19/2011 10:17:00 AM

0

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

Shao Miller

5/19/2011 12:23:00 PM

0

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.3.5/gcc/Function-Names.html#Func...