Re: [ANN] Lua 5.4.0 (work2) now available

[Sean Conner <sean@...>]

It was thus said that the Great Philippe Verdy once stated:
> 
> You need the modern support of "stdtype" (initially from the ANSI
> standard, or at least C99 and later) defining basic native types more
> strictly than what basic C types provide.

  No.  You'll need at least C89 and code like the following:

#include <limits.h>
#if CHAR_BIT == 8
  typedef unsigned char uint8_t;
#else
#  error Not a byte-addressible system (at least this is the assumption).
#endif

#if USHRT_MAX == 65536u
  typedef unsighed short uint16_t;
#else
#  error Can not compile with 16-bit types
#endif

#if UINT_MAX == 4294967295UL
  typedef unsigned int uint32_t;
#elif ULONG_MAX == 4294967295UL
  typedef unsigned long uint32_t;
#else
#  error Can not compile with 32-bit types
#endif

#if ULONG_MAX == 18446744073709551615ULL
  typedef unsigned long uint64_t;
#else
#  if defined(ULLONG_MAX)
#    if ULLONG_MAX == 18446744073709551615ULL
       typedef unsigned long long uint64_t;
#    else
#      error Can not compile with 64-bit types
#    endif
#  else
#    error No 64-bit support.
#  endif
#endif

  And so on ... Yes, annoying, but possible.

> I know that most modern C environments now have this "stdtype" library; but
> using it (and only it) has a known performance cost,
                                     ^^^^^^^^^^^^^^^^

  Only if the exact width integer types don't exist; uint16_t, uint32_t and
uint64_t aren't required, and here, I'll cite my source---ISO/IEC 9899:TC3
(aka, C99), section 7.18.1.1:

	3 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.

Required are int_least8_t, uint_least8_t, et. al. (7.18.1.2), and
int_fast8_t, uint_fast8_t et. al. (7.18.1.3).

> and it requires
> discipline of C programmers (i.e. not using the "int" datatype at all, and
> not even "char", "float" and "double" without an overlay reimplementing if
> needed the standard types and the standard artithmetic and mathemetic
> operations); or it requires a C compiler that will enforce these limits
> using a more precise set of limits for all basic C types (char, short, int,
> long, long long, and their signed/unsigned variants, plus bool, float and
> double) and defining stricter semantics for or for evaluation order and
                                                 ^^^^^^^^^^^^^^^^^^^^
> allowed "aliasings" caused by pointers and references, as well as exception
  ^^^^^^^^^^^^^^^^^^^                                               ^^^^^^^^^
> handlers (this may also require using specific versions of the standard C
  ^^^^^^^^
> library compiled with these stricter rules).

  [Citation needed]

  -spc