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))