Difference between revisions of "Portability assumptions"
(→C compiler: Add signed<>unsigned conversion stuff. Clean up wording.) 

Line 18:  Line 18:  
We require behavior that C89 formally declares to be implementationdefined: 
We require behavior that C89 formally declares to be implementationdefined: 

−  * Characters are 8 bits wide. 
+  * Characters are 8 bits wide. (This is a POSIX requirement.) 
* Signed integers are represented as two'scomplement, and all possible bit combinations represent valid values. (The absolute value of the bounds are not the same.) 
* Signed integers are represented as two'scomplement, and all possible bit combinations represent valid values. (The absolute value of the bounds are not the same.) 

* Converting an unsigned integer to the corresponding signed integer type when the unsigned integer value is larger than the largest signed integer value will preserve the bit pattern of the representation. (Equivalently, the conversion from a negative signed integer to the corresponding unsigned integer type is invertible.) 
* Converting an unsigned integer to the corresponding signed integer type when the unsigned integer value is larger than the largest signed integer value will preserve the bit pattern of the representation. (Equivalently, the conversion from a negative signed integer to the corresponding unsigned integer type is invertible.) 

* Integers have no padding bits. 
* Integers have no padding bits. 

+  * <code>int</code> is at least 32 bits wide. (This is a POSIX requirement.) This may limit portability to some more constrained embedded platforms. 

We require some behavior that C89 formally declares to be undefined: 
We require some behavior that C89 formally declares to be undefined: 
Revision as of 15:11, 24 May 2012
This page represents a proposed policy of the MIT Kerberos project.
This is a partial list of portability assumptions made by the MIT krb5 source code.
C compiler
We assume a C compilation environment equivalent to a freestanding C89 (ISO/IEC 9899:1990) implementation. Freestanding language support for C99 (ISO/IEC 9899:1999) does not have to be complete, but we use some C99 features:
 The C99
inline
feature should be supported.  External identifiers of at least 31 significant initial characters should be supported.
 The
long long int
type, or some reasonably equivalent means of declaring integers of at least 64 bits of precision, should be supported.  Variadic macros should be supported.
We require behavior that C89 formally leaves unspecified:
 Null pointers are represented as all bits zero. This means that pointer members of a structure can be initialized to null pointer values by
calloc()
ormemset()
.
We require behavior that C89 formally declares to be implementationdefined:
 Characters are 8 bits wide. (This is a POSIX requirement.)
 Signed integers are represented as two'scomplement, and all possible bit combinations represent valid values. (The absolute value of the bounds are not the same.)
 Converting an unsigned integer to the corresponding signed integer type when the unsigned integer value is larger than the largest signed integer value will preserve the bit pattern of the representation. (Equivalently, the conversion from a negative signed integer to the corresponding unsigned integer type is invertible.)
 Integers have no padding bits.

int
is at least 32 bits wide. (This is a POSIX requirement.) This may limit portability to some more constrained embedded platforms.
We require some behavior that C89 formally declares to be undefined:
 Pointers to
void
can be cast to pointers to functions.
C runtime libraries
We expect that substantially all of the C89 and SUSv3/POSIX.1 library interfaces are available. We expect POSIX signal interfaces to be available on Unixlike platforms.
We expect that IPv4 and IPv6 networking support is available, via either the BSD or Windows socket interfaces.
If the platform supports threads, we expect that normal (nonrecursive) mutexes can be locked and unlocked without risk of failure, assuming correct usage.
We expect that the snprintf()
family of functions from C99 and SUSv3/POSIX.1 is available and either conforms to the standards or deviates from the standard behavior in one of a small number of ways:
 It may return 1 if the target buffer is not sufficiently large.
 It may treat
n
of zero or a null target pointer as an error condition.
On Solaris, precision specifiers on string formats in printf()
family functions may count columns rather than bytes if the application is not compiled in a standardconforming environment. We are investigating the security impact of this behavior.
The C99 stdint.h
or inttypes.h
capabilities should be available.
We require behavior that is specified by C89, but historical implementations have failed to provide:

free()
andrealloc()
must work on null pointers.
Relevant mailing list discussions
http://mailman.mit.edu/pipermail/krbdev/2012January/010652.html