Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: gcc_centric C code Date: Wed, 25 Apr 2018 10:54:08 -0700 Organization: None to speak of Lines: 45 Message-ID: References: <87tvrzpa32.fsf@bsb.me.uk> <29063935-b373-4307-be80-78a64134d0e7@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="6422cd8020e26cadac40843395f612df"; logging-data="12454"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Kew+cFibqdw5cdN5ncnYs" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:ij6VkUFTQgM3aYRCJqm+tVNt9VY= sha1:cZYThRUtJVLvphKGsR/z+f+sfXs= Xref: csiph.com comp.lang.c:129736 Robert Wessel writes: > On Wed, 25 Apr 2018 10:30:03 -0700 (PDT), supercat@casperkitty.com > wrote: >>On Wednesday, April 25, 2018 at 11:19:27 AM UTC-5, Spiros Bousbouras wrote: >>> Yes and I use it all the time for error messages. But it's not a macro , >>> it's an identifier : >>> >>> 6.4.2.2 Predefined identifiers >>> Semantics >>> >>> 1 The identifier __func__ shall be implicitly declared by the >>> translator as if, immediately following the opening brace of each >>> function definition, the declaration >>> static const char __func__[] = "function-name"; >>> appeared, where function-name is the name of the lexically-enclosing >>> function.61) >>> >>> 2 This name is encoded as if the implicit declaration had been written >>> in the source character set and then translated into the execution >>> character set as indicated in translation phase 5. >> >>I wonder if there's any particular advantage to doing that, versus saying >>having it be a token which behaves like a string literal? Being able to >>combine the other built-ins that yield strings, e.g. >> >> const char build_info[] = "Version 1.3 " __DATE__ " " __TIME__; >> >>is certainly useful, and I see no reason that giving __func__ such >>abilities would not be similarly useful. >> >>Would having __func__ be a token that behaves like a quoted string literal >>cause any "translation phase" issue? > > Yes, expanding those macros and the concatenation of adjacent string > literals happens long before the boundaries of functions are > determined. A very minor point: values yielded by __func__ can be compared for pointer equality. (I've never seen code that relies on this.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"