* RFC: __FUNCTION__ and __PRETTY_FUNCTION__ @ 2001-12-09 10:16 Neil Booth 2001-12-09 11:48 ` Joseph S. Myers 0 siblings, 1 reply; 18+ messages in thread From: Neil Booth @ 2001-12-09 10:16 UTC (permalink / raw) To: gcc; +Cc: aj As Andreas pointed out, my string concatenation patches break the concatenation of these functions. They are documented as undergoing concatenation. However, g++ does _not_ concatenate these; it gives a parse error. Only the C/ObjC front end concatenates them. Until yesterday, anyway 8^) I think their undergoing concatenation is wrong and a poor design decision: it is a violation of strict ordering of the ISO C and C++ standards, since by the time we are compiling in phase 7, phase 6 string concatenation should already have been done. So, since g++ does not concatenate these, and it makes moving string concatenation out of the parser difficult, I would like to propose changing the documentation to state that they do not concatenate. Thoughts? Neil. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__ 2001-12-09 10:16 RFC: __FUNCTION__ and __PRETTY_FUNCTION__ Neil Booth @ 2001-12-09 11:48 ` Joseph S. Myers 2001-12-09 15:02 ` Neil Booth 0 siblings, 1 reply; 18+ messages in thread From: Joseph S. Myers @ 2001-12-09 11:48 UTC (permalink / raw) To: Neil Booth; +Cc: gcc On Sun, 9 Dec 2001, Neil Booth wrote: > So, since g++ does not concatenate these, and it makes moving string > concatenation out of the parser difficult, I would like to propose > changing the documentation to state that they do not concatenate. I think we should make them follow the C99 definition of __func__. You'll need to decide whether they should be three distinct objects even if their contents are all the same; they probably should (be distinct from each other and from string literals) for consistency with __func__. -- Joseph S. Myers jsm28@cam.ac.uk ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__ 2001-12-09 11:48 ` Joseph S. Myers @ 2001-12-09 15:02 ` Neil Booth 2001-12-09 15:13 ` Joseph S. Myers 2001-12-10 0:21 ` Andreas Jaeger 0 siblings, 2 replies; 18+ messages in thread From: Neil Booth @ 2001-12-09 15:02 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc Joseph S. Myers wrote:- > I think we should make them follow the C99 definition of __func__. OK, I'm all for that. I've had one other vote in favour of consistency with g++. > You'll need to decide whether they should be three distinct objects even > if their contents are all the same; they probably should (be distinct from > each other and from string literals) for consistency with __func__. Are you saying that, within the same function, __func__ and __FUNCTION__ should be distinct? I'm not persuaded. I'm guessing that the reason the standard specified the uniqueness criterion was so that you could easily compare functions based on __func__ (quite why you might want to do this isn't so clear to me). If the pointers are the same, then you unambiguously have the same function. Do you find this reasoning persuasive? I'm concerned about having the three distinct for the same function; having them the same seems better to me on first thoughts. If I produced a patch to do one or the other, would you accept it for 3.1? Neil. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__ 2001-12-09 15:02 ` Neil Booth @ 2001-12-09 15:13 ` Joseph S. Myers 2001-12-10 0:21 ` Andreas Jaeger 1 sibling, 0 replies; 18+ messages in thread From: Joseph S. Myers @ 2001-12-09 15:13 UTC (permalink / raw) To: Neil Booth; +Cc: gcc On Sun, 9 Dec 2001, Neil Booth wrote: > Are you saying that, within the same function, __func__ and > __FUNCTION__ should be distinct? I'm not persuaded. I'm guessing > that the reason the standard specified the uniqueness criterion was so > that you could easily compare functions based on __func__ (quite why > you might want to do this isn't so clear to me). If the pointers are > the same, then you unambiguously have the same function. The reason they are distinct is a basic presumption that named objects are distinct; see the thread on "Merging objects" on comp.std.c, November 2000. Having all three distinct would thus be more consistent with the workings of C. -- Joseph S. Myers jsm28@cam.ac.uk ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__ 2001-12-09 15:02 ` Neil Booth 2001-12-09 15:13 ` Joseph S. Myers @ 2001-12-10 0:21 ` Andreas Jaeger 2001-12-10 0:56 ` Joseph S. Myers ` (2 more replies) 1 sibling, 3 replies; 18+ messages in thread From: Andreas Jaeger @ 2001-12-10 0:21 UTC (permalink / raw) To: Neil Booth; +Cc: Joseph S. Myers, gcc Neil Booth <neil@daikokuya.demon.co.uk> writes: > Joseph S. Myers wrote:- > >> I think we should make them follow the C99 definition of __func__. > > OK, I'm all for that. I've had one other vote in favour of consistency > with g++. If we do that - like your patches on gcc-patches do - we break compatibilty with existing code without a really good reason. __FUNCTION__ is a well documented extension and you break it, forcing users to change their code. It might have been a better design decision to implement __FUNCTION__ like __func__ but the designers of __FUNCTION__ did it as documented - and this simplifies application code, glibc e.g. does: extern void __libc_fatal (__const char *__message) # define LOG(c) if (__td_debug) __libc_write (2, c "\n", strlen (c "\n")) ... __libc_fatal ("illegal status in " __FUNCTION__); LOG (__FUNCTION__); Both usages do break and there're others that might do. I'd prefer to deprecate (iff this is really the meaning of the majority) this in GCC 3.1 and change it for GCC 3.2. If I'm overruled and everybody likes this change, then please send a patch that (I hope this is usual practice, if not, I'd propose it): - prominently says that this was changed, e.g. in a NEWS section - mentions in the description of __FUNCTION__ this change. People converting from older GCCs should see that something has changed! Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__ 2001-12-10 0:21 ` Andreas Jaeger @ 2001-12-10 0:56 ` Joseph S. Myers 2001-12-10 10:34 ` Neil Booth 2001-12-10 1:46 ` Nathan Sidwell 2001-12-10 11:14 ` Mark Mitchell 2 siblings, 1 reply; 18+ messages in thread From: Joseph S. Myers @ 2001-12-10 0:56 UTC (permalink / raw) To: Andreas Jaeger; +Cc: Neil Booth, gcc On Mon, 10 Dec 2001, Andreas Jaeger wrote: > without a really good reason. That the code is cleaned up to put string concatenation in a single more appropriate place. That the original extension was fundamentally badly designed in terms of the workings of C. > - prominently says that this was changed, e.g. in a NEWS section htdocs/gcc-3.1/caveats.html is the appropriate place. -- Joseph S. Myers jsm28@cam.ac.uk ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__ 2001-12-10 0:56 ` Joseph S. Myers @ 2001-12-10 10:34 ` Neil Booth 0 siblings, 0 replies; 18+ messages in thread From: Neil Booth @ 2001-12-10 10:34 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Andreas Jaeger, gcc Joseph S. Myers wrote:- > On Mon, 10 Dec 2001, Andreas Jaeger wrote: > > > without a really good reason. > > That the code is cleaned up to put string concatenation in a single more > appropriate place. That the original extension was fundamentally badly > designed in terms of the workings of C. And it makes gcc the same as g++. Neil. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__ 2001-12-10 0:21 ` Andreas Jaeger 2001-12-10 0:56 ` Joseph S. Myers @ 2001-12-10 1:46 ` Nathan Sidwell 2001-12-10 10:49 ` Neil Booth 2001-12-10 11:14 ` Mark Mitchell 2 siblings, 1 reply; 18+ messages in thread From: Nathan Sidwell @ 2001-12-10 1:46 UTC (permalink / raw) To: Andreas Jaeger; +Cc: Neil Booth, Joseph S. Myers, gcc, Richard Henderson, zack Andreas Jaeger wrote: > > Neil Booth <neil@daikokuya.demon.co.uk> writes: > > > Joseph S. Myers wrote:- > > > >> I think we should make them follow the C99 definition of __func__. > > > > OK, I'm all for that. I've had one other vote in favour of consistency > > with g++. When Zack & I implemented the lazy __FUNCTION__ generation back in April, I asked about making them all behave like __func__. The consensus then was a NO. We'd be breaking lots of important code bases. my suggestion: http://gcc.gnu.org/ml/gcc-patches/2001-03/msg01506.html zack's response: http://gcc.gnu.org/ml/gcc-patches/2001-03/msg01556.html 1) If this is removed, then it must be done via deprecation in 3.1 and removal in 3.2 2) More heads need to consider the impact of such a change nathan -- Dr Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC 'But that's a lie.' - 'Yes it is. What's your point?' nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__ 2001-12-10 1:46 ` Nathan Sidwell @ 2001-12-10 10:49 ` Neil Booth 0 siblings, 0 replies; 18+ messages in thread From: Neil Booth @ 2001-12-10 10:49 UTC (permalink / raw) To: Nathan Sidwell Cc: Andreas Jaeger, Joseph S. Myers, gcc, Richard Henderson, zack Nathan Sidwell wrote:- > 1) If this is removed, then it must be done via deprecation in 3.1 > and removal in 3.2 > 2) More heads need to consider the impact of such a change There's still time to deprecate it in 3.0.3. I can submit a patch to warn when __FUNCTION__ or __PRETTY_FUNCTION__ is concatenated with something else, and update the docs too. Neil. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__ 2001-12-10 0:21 ` Andreas Jaeger 2001-12-10 0:56 ` Joseph S. Myers 2001-12-10 1:46 ` Nathan Sidwell @ 2001-12-10 11:14 ` Mark Mitchell 2001-12-10 12:12 ` Neil Booth ` (3 more replies) 2 siblings, 4 replies; 18+ messages in thread From: Mark Mitchell @ 2001-12-10 11:14 UTC (permalink / raw) To: Andreas Jaeger, Neil Booth; +Cc: Joseph S. Myers, gcc --On Monday, December 10, 2001 08:30:45 AM +0100 Andreas Jaeger <aj@suse.de> wrote: > Neil Booth <neil@daikokuya.demon.co.uk> writes: > >> Joseph S. Myers wrote:- >> >>> I think we should make them follow the C99 definition of __func__. >> >> OK, I'm all for that. I've had one other vote in favour of consistency >> with g++. I think this is a difficult question. It's clear that the change Neil and Joseph are in favor of is an improvement from the point of view of language semantics. Making __FUNCTION__ behave like __func__ is a good thing; the __func__ semantics are better. The GCC simplifications resulting are real and significant. Neil has proposed deprecating this in GCC 3.0.3 so that we can then not support it in GCC 3.1. Deprecating something in a dot-release is a little dodgy. Andreas suggested deprecating it in 3.1 and removing it 3.2, which is definitely less dodgy -- but also means we have to remember this debate for several more months -- at least until after we branch for 3.1 in February. There may be others who do not want to break compatibility here at all. This is a change that will cause people to have to fiddle with various assertion macros in their software; the changes aren't too hard, but there will probably be a lot of changes. I agree with Andreas, i.e, deprecate this in 3.1, and remove it 3.2. Therefore, I would pre-approve the patch for the moment that the 3.1 branch is announce, and pre-approve a deprecation patch for both 3.0.3 and 3.1. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__ 2001-12-10 11:14 ` Mark Mitchell @ 2001-12-10 12:12 ` Neil Booth 2001-12-10 12:16 ` Mark Mitchell 2001-12-10 13:03 ` DJ Delorie ` (2 subsequent siblings) 3 siblings, 1 reply; 18+ messages in thread From: Neil Booth @ 2001-12-10 12:12 UTC (permalink / raw) To: Mark Mitchell; +Cc: Andreas Jaeger, Joseph S. Myers, gcc Mark Mitchell wrote:- > I agree with Andreas, i.e, deprecate this in 3.1, and remove it 3.2. > Therefore, I would pre-approve the patch for the moment that the 3.1 > branch is announce, and pre-approve a deprecation patch for both > 3.0.3 and 3.1. Thanks Mark. I've just reverted the concatenation patch; I'll keep them around for 3.2. I'll come up with something to give a warning for 3.1 and 3.0. Neil. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__ 2001-12-10 12:12 ` Neil Booth @ 2001-12-10 12:16 ` Mark Mitchell 0 siblings, 0 replies; 18+ messages in thread From: Mark Mitchell @ 2001-12-10 12:16 UTC (permalink / raw) To: Neil Booth; +Cc: Andreas Jaeger, Joseph S. Myers, gcc --On Monday, December 10, 2001 08:09:11 PM +0000 Neil Booth <neil@daikokuya.demon.co.uk> wrote: > Mark Mitchell wrote:- > >> I agree with Andreas, i.e, deprecate this in 3.1, and remove it 3.2. >> Therefore, I would pre-approve the patch for the moment that the 3.1 >> branch is announce, and pre-approve a deprecation patch for both >> 3.0.3 and 3.1. > > Thanks Mark. I've just reverted the concatenation patch; I'll keep > them around for 3.2. > > I'll come up with something to give a warning for 3.1 and 3.0. Thanks. I should have explicitly said that this is not my call to make in a unilateral fashion; if other people have opinions they should weigh in. However, absent a countermanding order, please proceed as I suggested. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__ 2001-12-10 11:14 ` Mark Mitchell 2001-12-10 12:12 ` Neil Booth @ 2001-12-10 13:03 ` DJ Delorie 2001-12-10 13:16 ` Neil Booth 2001-12-10 14:12 ` Mark Mitchell 2001-12-10 19:12 ` Richard Henderson 2001-12-11 12:29 ` Joe Buck 3 siblings, 2 replies; 18+ messages in thread From: DJ Delorie @ 2001-12-10 13:03 UTC (permalink / raw) To: mark; +Cc: aj, neil, jsm28, gcc > Andreas suggested deprecating it in 3.1 and removing it 3.2, which > is definitely less dodgy -- but also means we have to remember this > debate for several more months -- at least until after we branch for > 3.1 in February. Could we add a commented #if in a relevent part of the gcc sources that triggers off the 3.2 version number and causes a compile error? Then at least the person bumping the version number can remove the error and post a note to restart the discussion. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__ 2001-12-10 13:03 ` DJ Delorie @ 2001-12-10 13:16 ` Neil Booth 2001-12-10 14:12 ` Mark Mitchell 1 sibling, 0 replies; 18+ messages in thread From: Neil Booth @ 2001-12-10 13:16 UTC (permalink / raw) To: DJ Delorie; +Cc: mark, gcc DJ Delorie wrote:- > Could we add a commented #if in a relevent part of the gcc sources > that triggers off the 3.2 version number and causes a compile error? > Then at least the person bumping the version number can remove the > error and post a note to restart the discussion. Don't worry, I have no intention of forgetting. The patch will reappear within 24hrs of branch if I'm not on holiday. 8-) Neil. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__ 2001-12-10 13:03 ` DJ Delorie 2001-12-10 13:16 ` Neil Booth @ 2001-12-10 14:12 ` Mark Mitchell 1 sibling, 0 replies; 18+ messages in thread From: Mark Mitchell @ 2001-12-10 14:12 UTC (permalink / raw) To: DJ Delorie; +Cc: aj, neil, jsm28, gcc --On Monday, December 10, 2001 03:58:34 PM -0500 DJ Delorie <dj@redhat.com> wrote: > >> Andreas suggested deprecating it in 3.1 and removing it 3.2, which >> is definitely less dodgy -- but also means we have to remember this >> debate for several more months -- at least until after we branch for >> 3.1 in February. > > Could we add a commented #if in a relevent part of the gcc sources > that triggers off the 3.2 version number and causes a compile error? > Then at least the person bumping the version number can remove the > error and post a note to restart the discussion. We could -- but I think we can trust Neil to remember. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__ 2001-12-10 11:14 ` Mark Mitchell 2001-12-10 12:12 ` Neil Booth 2001-12-10 13:03 ` DJ Delorie @ 2001-12-10 19:12 ` Richard Henderson 2001-12-10 21:01 ` Mark Mitchell 2001-12-11 12:29 ` Joe Buck 3 siblings, 1 reply; 18+ messages in thread From: Richard Henderson @ 2001-12-10 19:12 UTC (permalink / raw) To: Mark Mitchell; +Cc: Andreas Jaeger, Neil Booth, Joseph S. Myers, gcc On Mon, Dec 10, 2001 at 11:04:10AM -0800, Mark Mitchell wrote: > I agree with Andreas, i.e, deprecate this in 3.1, and remove it 3.2. > Therefore, I would pre-approve the patch for the moment that the 3.1 > branch is announce, and pre-approve a deprecation patch for both > 3.0.3 and 3.1. If we've decided that we're going to deprecate this in 3.1, why bother waiting for branch date? Just deprecate it on mainline now. r~ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__ 2001-12-10 19:12 ` Richard Henderson @ 2001-12-10 21:01 ` Mark Mitchell 0 siblings, 0 replies; 18+ messages in thread From: Mark Mitchell @ 2001-12-10 21:01 UTC (permalink / raw) To: Richard Henderson; +Cc: Andreas Jaeger, Neil Booth, Joseph S. Myers, gcc --On Monday, December 10, 2001 06:40:00 PM -0800 Richard Henderson <rth@redhat.com> wrote: > On Mon, Dec 10, 2001 at 11:04:10AM -0800, Mark Mitchell wrote: >> I agree with Andreas, i.e, deprecate this in 3.1, and remove it 3.2. >> Therefore, I would pre-approve the patch for the moment that the 3.1 >> branch is announce, and pre-approve a deprecation patch for both >> 3.0.3 and 3.1. > > If we've decided that we're going to deprecate this in 3.1, why > bother waiting for branch date? Just deprecate it on mainline now. I must have been unclear -- that's what I meant. I just wanted to avoid checking in the actual change to the semantics until after 3.1 has been branched. Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__ 2001-12-10 11:14 ` Mark Mitchell ` (2 preceding siblings ...) 2001-12-10 19:12 ` Richard Henderson @ 2001-12-11 12:29 ` Joe Buck 3 siblings, 0 replies; 18+ messages in thread From: Joe Buck @ 2001-12-11 12:29 UTC (permalink / raw) To: Mark Mitchell; +Cc: Andreas Jaeger, Neil Booth, Joseph S. Myers, gcc Mark writes: > I think this is a difficult question. It's clear that the change > Neil and Joseph are in favor of is an improvement from the point of > view of language semantics. Making __FUNCTION__ behave like __func__ > is a good thing; the __func__ semantics are better. The GCC > simplifications resulting are real and significant. > > Neil has proposed deprecating this in GCC 3.0.3 so that we can > then not support it in GCC 3.1. Deprecating something in a > dot-release is a little dodgy. > > Andreas suggested deprecating it in 3.1 and removing it 3.2, which > is definitely less dodgy -- but also means we have to remember this > debate for several more months -- at least until after we branch for > 3.1 in February. You could go ahead and do the deprecation in the trunk now, since it will become 3.1. The last time we fought about something like this in the SC (-traditional), the consensus seemed to be be against deprecating something in a bug-fix release (e.g. 3.0.3) that wasn't deprecated before. This means that it's harder and takes longer to make features go away, but that's a *good* thing. We should be slow and careful either in adding extensions or in taking them away. > I agree with Andreas, i.e, deprecate this in 3.1, and remove it 3.2. > Therefore, I would pre-approve the patch for the moment that the 3.1 > branch is announce, and pre-approve a deprecation patch for both > 3.0.3 and 3.1. OK with me. I think there's no problem with your approving this unless some SC member objects. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2001-12-11 20:19 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-12-09 10:16 RFC: __FUNCTION__ and __PRETTY_FUNCTION__ Neil Booth 2001-12-09 11:48 ` Joseph S. Myers 2001-12-09 15:02 ` Neil Booth 2001-12-09 15:13 ` Joseph S. Myers 2001-12-10 0:21 ` Andreas Jaeger 2001-12-10 0:56 ` Joseph S. Myers 2001-12-10 10:34 ` Neil Booth 2001-12-10 1:46 ` Nathan Sidwell 2001-12-10 10:49 ` Neil Booth 2001-12-10 11:14 ` Mark Mitchell 2001-12-10 12:12 ` Neil Booth 2001-12-10 12:16 ` Mark Mitchell 2001-12-10 13:03 ` DJ Delorie 2001-12-10 13:16 ` Neil Booth 2001-12-10 14:12 ` Mark Mitchell 2001-12-10 19:12 ` Richard Henderson 2001-12-10 21:01 ` Mark Mitchell 2001-12-11 12:29 ` Joe Buck
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).