static void NAME()

in auth/kinit_client/k5-platform.h [392:508]


        static void NAME(void)

# else /* not hpux */

#  define MAKE_FINI_FUNCTION(NAME)      \
        void NAME(void)

# endif

#elif !defined(SHARED)

/*
 * In this case, we just don't care about finalization.  The code will still
 * define the function, but we won't do anything with it.
 */
# define MAKE_FINI_FUNCTION(NAME)               \
        static void NAME(void) UNUSED

#elif defined(__GNUC__) && defined(DESTRUCTOR_ATTR_WORKS)
/* If we're using gcc, if the C++ support works, the compiler should
   build executables and shared libraries that support the use of
   static constructors and destructors.  The C compiler supports a
   function attribute that makes use of the same facility as C++.

   XXX How do we know if the C++ support actually works?  */
# define MAKE_FINI_FUNCTION(NAME)       \
        static void NAME(void) __attribute__((destructor))

#else

# error "Don't know how to do unload-time finalization for this configuration."

#endif

#ifndef SIZE_MAX
# define SIZE_MAX ((size_t)((size_t)0 - 1))
#endif

#ifdef _WIN32
# define SSIZE_MAX ((ssize_t)(SIZE_MAX/2))
#endif

/* Read and write integer values as (unaligned) octet strings in
   specific byte orders.  Add per-platform optimizations as
   needed.  */

#if HAVE_ENDIAN_H
# include <endian.h>
#elif HAVE_MACHINE_ENDIAN_H
# include <machine/endian.h>
#endif
/* Check for BIG/LITTLE_ENDIAN macros.  If exactly one is defined, use
   it.  If both are defined, then BYTE_ORDER should be defined and
   match one of them.  Try those symbols, then try again with an
   underscore prefix.  */
#if defined(BIG_ENDIAN) && defined(LITTLE_ENDIAN)
# if BYTE_ORDER == BIG_ENDIAN
#  define K5_BE
# endif
# if BYTE_ORDER == LITTLE_ENDIAN
#  define K5_LE
# endif
#elif defined(BIG_ENDIAN)
# define K5_BE
#elif defined(LITTLE_ENDIAN)
# define K5_LE
#elif defined(_BIG_ENDIAN) && defined(_LITTLE_ENDIAN)
# if _BYTE_ORDER == _BIG_ENDIAN
#  define K5_BE
# endif
# if _BYTE_ORDER == _LITTLE_ENDIAN
#  define K5_LE
# endif
#elif defined(_BIG_ENDIAN)
# define K5_BE
#elif defined(_LITTLE_ENDIAN)
# define K5_LE
#elif defined(__BIG_ENDIAN__) && !defined(__LITTLE_ENDIAN__)
# define K5_BE
#elif defined(__LITTLE_ENDIAN__) && !defined(__BIG_ENDIAN__)
# define K5_LE
#endif
#if !defined(K5_BE) && !defined(K5_LE)
/* Look for some architectures we know about.

   MIPS can use either byte order, but the preprocessor tells us which
   mode we're compiling for.  The GCC config files indicate that
   variants of Alpha and IA64 might be out there with both byte
   orders, but until we encounter the "wrong" ones in the real world,
   just go with the default (unless there are cpp predefines to help
   us there too).

   As far as I know, only PDP11 and ARM (which we don't handle here)
   have strange byte orders where an 8-byte value isn't laid out as
   either 12345678 or 87654321.  */
# if defined(__i386__) || defined(_MIPSEL) || defined(__alpha__) || (defined(__ia64__) && !defined(__hpux))
#  define K5_LE
# endif
# if defined(__hppa__) || defined(__rs6000__) || defined(__sparc__) || defined(_MIPSEB) || defined(__m68k__) || defined(__sparc64__) || defined(__ppc__) || defined(__ppc64__) || (defined(__hpux) && defined(__ia64__))
#  define K5_BE
# endif
#endif
#if defined(K5_BE) && defined(K5_LE)
# error "oops, check the byte order macros"
#endif

/* Optimize for GCC on platforms with known byte orders.

   GCC's packed structures can be written to with any alignment; the
   compiler will use byte operations, unaligned-word operations, or
   normal memory ops as appropriate for the architecture.

   This assumes the availability of uint##_t types, which should work
   on most of our platforms except Windows, where we're not using
   GCC.  */
#ifdef __GNUC__
# define PUT(SIZE,PTR,VAL)      (((struct { uint##SIZE##_t i; } __attribute__((packed)) *)(PTR))->i = (VAL))