Russ Allbery wrote:
Jeffrey Hutzelman <[EMAIL PROTECTED]> writes:
"Douglas E. Engert" <[EMAIL PROTECTED]> wrote:
The correct way for AFS is it test for HAVE_FUNCTION_MACRO which
configure will set if the compiler can handle __FUNCTION__. Then again
the new rxk5/servconn.c is the only source routines in AFS that uses
__FUNCTION__ as far as I can tell.
I think we're talking about two different issues.
Yes, obviously we shouldn't use __FUNCTION__ if it isn't available.
Unfortunately, I'm pretty sure it's _not_ a preprocessor macro, which
means you can't test for it with #ifdef -- someone will have to write a
real test to see if it's there. Or we could just avoid using it.
There is a real test, src/cf/function-macro.m4 and AFS configure
will call it and set HAVE_FUNCTION_MACRO. So far AFS has avoided using
__FUNCTION__, accept in this one case in new test code where it is not really
needed.
__FUNCTION__ is a gccism.
/* __func__ is C99, but not provided by all implementations. */
#if __STDC_VERSION__ < 199901L
# if __GNUC__ >= 2
# define __func__ __FUNCTION__
# else
# define __func__ "<unknown>"
# endif
#endif
works for pam-krb5 and pam-afs-session.
But my point wasn't about "how do we deal with __FUNCTION__ not
existing", or even "what should we use here". It was lower-level than
that -- if what you want to do is concatenate __FILE__ and a literal
string, the way to do so is with juxtaposition.
This may not work in all cases since, for whatever reason, some compilers
implement __func__ or __FUNCTION__ as a weird static string instead of a
literal and concatenation doesn't work. Annoying.
Yes, its annoying. But the Solaris compiler is used to compile OpenAFS.
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
