<commit_before>#ifndef __EVILIBC_STDINT_H
#define __EVILIBC_STDINT_H

#include <unistd.h>

#ifdef __cplusplus
extern "C" {
#endif

#define __INT8_MIN__ (-128)
#define __INT8_MAX__ 127
#define __INT16_MIN__ (-32768)
#define __INT16_MAX__ 32767
#define __INT32_MIN__ (-2147483648)
#define __INT32_MAX__ 2147483647
#define __INT64_MIN__ (-9223372036854775808LL)
#define __INT64_MAX__ 9223372036854775807LL

#define __UINT8_MAX__ 255
#define __UINT16_MAX__ 65535
#define __UINT32_MAX__ 4294967295
#define __UINT64_MAX__ 18446744073709551615ULL

/*
 * 7.20.1.1 Exact-width integer types:
 * > These types are optional. However, if an implementation provides integer
 * > types with widths of 8, 16, 32, or 64 bits, no padding bits, and (for the
 * > signed types) that have a two’s complement representation, it shall define
 * > the corresponding typedef names.
 *
 * POSIX requires exact-width types up to 32-bit ones to be present though.
 *
 * TODO: only fixed-width types are required to be two's complement. Would
 * it be technically correct to have different types have different encodings?
 * I.e. sign-magitude for for int_leastN_y and U2 for int_fastN_t?
 * TODO: some stupid 9-bit-based architecture and a compiler that does not
 * have these.
 * NOTE: that would no longer be POSIX; it requires CHAR_BIT == 8
 */
#ifdef _POSIX_VERSION

typedef __INT8_TYPE__  int8_t;
typedef __INT16_TYPE__ int16_t;<commit_msg>Make stuff compile<commit_after>#ifndef __EVILIBC_STDINT_H
#define __EVILIBC_STDINT_H

#warning "TODO: figure out way to enable/disable POSIX"
//#include <unistd.h>

#ifdef __cplusplus
extern "C" {
#endif

#ifndef __INT8_MIN__
#define __INT8_MIN__ (-128)
#endif
#ifndef __INT8_MAX__
#define __INT8_MAX__ 127
#endif
#ifndef __INT16_MIN__
#define __INT16_MIN__ (-32768)
#endif
#ifndef __INT16_MAX__
#define __INT16_MAX__ 32767
#endif
#ifndef __INT32_MIN__
#define __INT32_MIN__ (-2147483648)
#endif
#ifndef __INT32_MAX__
#define __INT32_MAX__ 2147483647
#endif
#ifndef __INT64_MIN__
#define __INT64_MIN__ (-9223372036854775808LL)
#endif
#ifndef __INT64_MAX__
#define __INT64_MAX__ 9223372036854775807LL
#endif

#ifndef __UINT8_MAX__
#define __UINT8_MAX__ 255
#endif
#ifndef __UINT16_MAX__
#define __UINT16_MAX__ 65535
#endif
#ifndef __UINT32_MAX__
#define __UINT32_MAX__ 4294967295
#endif
#ifndef __UINT64_MAX__
#define __UINT64_MAX__ 18446744073709551615ULL
#endif

/*
 * 7.20.1.1 Exact-width integer types:
 * > These types are optional. However, if an implementation provides integer
 * > types with widths of 8, 16, 32, or 64 bits, no padding bits, and (for the
 * > signed types) that have a two’s complement representation, it shall define
 * > the corresponding typedef names.
 *
 * POSIX requires exact-width types up to 32-bit ones to be present though.
 *
 * TODO: only fixed-width types are required to be two's complement. Would
 * it be technically correct to have different types have different encodings?
 * I.e. sign-magitude for for int_leastN_y and U2 for int_fastN_t?
 * TODO: some stupid 9-bit-based architecture and a compiler that does not
 * have these.
 * NOTE: that would no longer be POSIX; it requires CHAR_BIT == 8
 */
#ifdef _POSIX_VERSION

typedef __INT8_TYPE__  int8_t;
typedef __INT16_TYPE__ int16_t;
{'fraction_non_alphanumeric': 0.07112068965517242, 'fraction_numerical': 0.10252463054187193, 'mean_word_length': 5.272200772200772, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 13, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 2, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3660436', 'n_tokens_mistral': 1359, 'n_tokens_neox': 1127, 'n_words': 379}