[OpenAFS-devel] rxk5 branch is ready; please test

[Russ Allbery]

Jeffrey Hutzelman <jhutz@cmu.edu> writes:
> "Douglas E. Engert" <deengert@anl.gov> 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 (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>