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
:
: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 tha
Assar Westerlund <[EMAIL PROTECTED]> writes on 24 Apr 2000 02:43:28 +0200
> 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
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?
>
:On Sat, 22 Apr 2000, attila! wrote:
:
:> '__func__ is not found for either the 'GENERIC' or 'hun' target.
:
:__func__ is a new feature in C99. It is an alias for the gcc feature
:__FUNCTION_NAME. Both give the name of the current function as a string.
:
:This feature should not be used unt
On Sat, 22 Apr 2000, attila! wrote:
> '__func__ is not found for either the 'GENERIC' or 'hun' target.
__func__ is a new feature in C99. It is an alias for the gcc feature
__FUNCTION_NAME. Both give the name of the current function as a string.
This feature should not be used until C99 be
...trying to upgrade from 4.0-CURRENT (last update 21 Jul 99) to
5.0-CURRENT (22 Apr at 0419 UCT) using cvsup over 56K.
I know, I know, I fell behind, but it was doing its thing --ran
for 272 days without even restarting X although the aux generator
fired up during a couple po
