YouCompleteMe/python/clang/3.1/include/limits.h
Strahinja Val Markovic 74c363ef60 These headers magically speed up completions.
Clang searches for these files and if it doesn't find them, completion is twice
as slow (or slower) than otherwise.

See this issue report for more details:
https://github.com/Rip-Rip/clang_complete/issues/17
2012-07-23 18:45:00 -07:00

118 lines
3.6 KiB
C

/*===---- limits.h - Standard header for integer sizes --------------------===*\
*
* Copyright (c) 2009 Chris Lattner
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*
\*===----------------------------------------------------------------------===*/
#ifndef __CLANG_LIMITS_H
#define __CLANG_LIMITS_H
/* The system's limits.h may, in turn, try to #include_next GCC's limits.h.
Avert this #include_next madness. */
#if defined __GNUC__ && !defined _GCC_LIMITS_H_
#define _GCC_LIMITS_H_
#endif
/* System headers include a number of constants from POSIX in <limits.h>.
Include it if we're hosted. */
#if __STDC_HOSTED__ && \
defined(__has_include_next) && __has_include_next(<limits.h>)
#include_next <limits.h>
#endif
/* Many system headers try to "help us out" by defining these. No really, we
know how big each datatype is. */
#undef SCHAR_MIN
#undef SCHAR_MAX
#undef UCHAR_MAX
#undef SHRT_MIN
#undef SHRT_MAX
#undef USHRT_MAX
#undef INT_MIN
#undef INT_MAX
#undef UINT_MAX
#undef LONG_MIN
#undef LONG_MAX
#undef ULONG_MAX
#undef CHAR_BIT
#undef CHAR_MIN
#undef CHAR_MAX
/* C90/99 5.2.4.2.1 */
#define SCHAR_MAX __SCHAR_MAX__
#define SHRT_MAX __SHRT_MAX__
#define INT_MAX __INT_MAX__
#define LONG_MAX __LONG_MAX__
#define SCHAR_MIN (-__SCHAR_MAX__-1)
#define SHRT_MIN (-__SHRT_MAX__ -1)
#define INT_MIN (-__INT_MAX__ -1)
#define LONG_MIN (-__LONG_MAX__ -1L)
#define UCHAR_MAX (__SCHAR_MAX__*2 +1)
#define USHRT_MAX (__SHRT_MAX__ *2 +1)
#define UINT_MAX (__INT_MAX__ *2U +1U)
#define ULONG_MAX (__LONG_MAX__ *2UL+1UL)
#ifndef MB_LEN_MAX
#define MB_LEN_MAX 1
#endif
#define CHAR_BIT __CHAR_BIT__
#ifdef __CHAR_UNSIGNED__ /* -funsigned-char */
#define CHAR_MIN 0
#define CHAR_MAX UCHAR_MAX
#else
#define CHAR_MIN SCHAR_MIN
#define CHAR_MAX __SCHAR_MAX__
#endif
/* C99 5.2.4.2.1: Added long long. */
#if __STDC_VERSION__ >= 199901
#undef LLONG_MIN
#undef LLONG_MAX
#undef ULLONG_MAX
#define LLONG_MAX __LONG_LONG_MAX__
#define LLONG_MIN (-__LONG_LONG_MAX__-1LL)
#define ULLONG_MAX (__LONG_LONG_MAX__*2ULL+1ULL)
#endif
/* LONG_LONG_MIN/LONG_LONG_MAX/ULONG_LONG_MAX are a GNU extension. It's too bad
that we don't have something like #pragma poison that could be used to
deprecate a macro - the code should just use LLONG_MAX and friends.
*/
#if defined(__GNU_LIBRARY__) ? defined(__USE_GNU) : !defined(__STRICT_ANSI__)
#undef LONG_LONG_MIN
#undef LONG_LONG_MAX
#undef ULONG_LONG_MAX
#define LONG_LONG_MAX __LONG_LONG_MAX__
#define LONG_LONG_MIN (-__LONG_LONG_MAX__-1LL)
#define ULONG_LONG_MAX (__LONG_LONG_MAX__*2ULL+1ULL)
#endif
#endif /* __CLANG_LIMITS_H */