RFC: __FUNCTION__ and __PRETTY_FUNCTION__

RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[Neil Booth]

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.

Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[Joseph S. Myers]

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

Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[Neil Booth]

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.

Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[Joseph S. Myers]

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

Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[Andreas Jaeger]

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

Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[Joseph S. Myers]

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

Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[Nathan Sidwell]

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

Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[Neil Booth]

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.

Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[Neil Booth]

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.

Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[Mark Mitchell]

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

Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[Neil Booth]

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.

Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[Mark Mitchell]

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

Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[DJ Delorie]

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

Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[Neil Booth]

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.

Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[Mark Mitchell]

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

Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[Richard Henderson]

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~

Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[Mark Mitchell]

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

Re: RFC: __FUNCTION__ and __PRETTY_FUNCTION__

[Joe Buck]

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.