but, in all this, the bottom line is that compilers, until
recently, barfed on __func__. to compile the kernel, I
substituted the function name in the printf statement... no
big deal, but not what was intended, which I presume was to
guarantee the correct function name, even if the function
name was changed or the code lifted and reused in another
function. after a few words in the programmers' universal
language and a quick RTFS exercise, the hack was in... on
with the show and the new kernel ran just fine and buildworld
has done its thing.
attila out...
--
No, I don't suffer from insanity - I enjoy every minute of it.
On Sun, 23 Apr 2000, Matthew Dillon wrote:
> :Matthew Dillon <[EMAIL PROTECTED]> writes:
> :> obviously missing __FUNCTION__ was added by GCC many years ago, but it was
> :> a while before it's use in defines in header (.h) files was dealt with
> :> properly.
> :
> :You mean outside a function? What's the proper way of dealing with that?
> :
> :> I wish these stupid standards committees would just choose
> :> something that people are already using rather then make up new names!
> :
> :The problem is that __func__ and __FUNCTION__ are not the same thing.
> :And thus it makes sense for them not the use same name.
> :
> :/assar
>
> __FUNCTION__ represents the name of the C procedure you are currently
> in, same as __func__ as far as I can tell.
>
> You can define macros that use __FUNCTION__ in header files and then
> use them in the C code. This works just fine, as of around 6 years
> ago (before then __FUNCTION__ in gnu C did not properly resolve when
> used in a macro in a header file).
>
> I use __FUNCTION__ all the time to implement ASSERT() macros.
>
> -Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
