logo_kerberos.gif

Difference between revisions of "Portability assumptions"

From K5Wiki
Jump to: navigation, search
(Updates resulting from January 2012 discussion)
Line 10: Line 10:
 
* External identifiers of at least 31 significant initial characters should be supported.
 
* External identifiers of at least 31 significant initial characters should be supported.
 
* The <code>long long int</code> type, or some reasonably equivalent means of declaring integers of at least 64 bits of precision, should be supported.
 
* The <code>long long int</code> 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 is formally unspecified by C89:
 
We require behavior that is formally unspecified by C89:
Line 27: Line 28:
 
== C runtime libraries ==
 
== C runtime libraries ==
   
We expect that substantially all of the C89 and SUSv3/POSIX.1 library interfaces are available.
+
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 Unix-like 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 (non-recursive) mutexes can be locked and unlocked without risk of failure, assuming correct usage.
   
 
We expect that the <code>snprintf()</code> 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:
 
We expect that the <code>snprintf()</code> 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:
Line 41: Line 42:
   
 
* <code>free()</code> and <code>realloc()</code> must work on null pointers.
 
* <code>free()</code> and <code>realloc()</code> must work on null pointers.
  +
  +
== Relevant mailing list discussions ==
  +
  +
http://mailman.mit.edu/pipermail/krbdev/2012-January/010652.html

Revision as of 15:44, 15 February 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. It currently duplicates some content from Supported platforms, which will be replaced with a pointer to this page in the future.

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 is formally unspecified by C89:

  • 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() or memset().

We require behavior that is formally implementation-defined by C89:

  • Characters are 8 bits wide.
  • Integers are represented as two's-complement.
  • Integers have no padding bits.

We require some behavior that is formally undefined by C89:

  • 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 Unix-like 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 (non-recursive) 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 standard-conforming 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() and realloc() must work on null pointers.

Relevant mailing list discussions

http://mailman.mit.edu/pipermail/krbdev/2012-January/010652.html