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.
__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. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
