logo_kerberos.gif

Difference between revisions of "Portability research"

From K5Wiki
Jump to: navigation, search
(→‎C99 Compiler Support)
(→‎Mixed Windows C Runtimes and malloc/free)
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
This page collects some research we have done into the portability of various platform features. See [[Portability assumptions]] for the assumptions we make about target platforms based on this and other knowledge.
  
This page collects some research we have done into the portability of various platform features. See [[Portability assumptions]] for the assumptions we make about target platforms based on this and other knowledge.
  +
  +
== Mixed Windows C Runtimes and malloc/free ==
  +
  +
While Unix-like platforms implement C library functions in a central library which is usually dynamically linked, on Windows these functions are implemented in a "C Runtime" (CRT) library provided by the compiler. Even if all DLLs and the application are compiled using Visual Studio, multiple versions of the CRT may be present within the same process. Compiler flags (particularly the debugging flag) can affect which CRT is used by a library or application, so multiple versions can be present.
  +
  +
http://siomsystems.com/mixing-visual-studio-versions/ describes some of the incompatibilities which may arise from mixing CRT versions. They include three categories:
  +
  +
1. Receiving a pointer from malloc() from one CRT and freeing it with free() from another CRT can cause heap corruption. This problem is eliminated if all CRTs come from Visual Studio 2010 or later, as malloc() simply calls HeapAlloc() with the default process heap.
  +
  +
2. Objects such as FILE handles may be incompatible in different versions of the CRT, although no concrete examples of incompatibilities are known.
  +
  +
3. Static data held by the CRT will have one instance per version of the CRT. In particular, calls to setenv() from one CRT will not be reflected by getenv() from another ({{bug|2636}}).
  +
  +
Although problem 1 will become less important as older versions of Visual Studio age out, our library APIs are careful to provide free functions such as krb5_free_unparsed_name() to match allocation functions. Our plugin APIs are not always as careful, but many of them are currently not used in the Windows build.
   
 
== C99 Compiler Support ==
  
== C99 Compiler Support ==
   
⚫
Full C99 support is common in modern Unix compilers, but is not present in Microsoft Visual C (see [http://blogs.msdn.com/b/vcblog/archive/2007/11/05/iso-c-standard-update.aspx this blog post]). Some C99 features are supported in MSVC; here is a partial list of supported and unsupported features based on experimenting with version 7.1 of the SDK:
  
  +
[This section should be updated to reflect that Visual Studio 2013 is required for the Windows build. Significantly more C99 features are supported by this version.]
  +
  ⚫
Full C99 support is common in compilers for modern Unix-like platforms, but is not present in Microsoft Visual C (see [http://blogs.msdn.com/b/vcblog/archive/2007/11/05/iso-c-standard-update.aspx this blog post]). Some C99 features are supported in MSVC; here is a partial list of supported and unsupported features based on experimenting with version 7.1 of the SDK:
   
 
* The // comment syntax is supported.
  
* The // comment syntax is supported.
 
* Variadic macros are supported.
  
* Variadic macros are supported.
−
* The "long long int" type is supported.
 +
* The "long long int" type is supported, as is the printf length modifier "ll".
  +
* stdint.h is supported.
  +
* Non-constant aggregate initializers of automatic variables are supported.
   
 
* inline functions are supported, but the keyword is __inline.
  
* inline functions are supported, but the keyword is __inline.
 
* MSVC defines __FUNCTION__ instead of C99's __func__.
  
* MSVC defines __FUNCTION__ instead of C99's __func__.
 
* va_copy is not supported, but va_list positions can be copied by assignment.
  
* va_copy is not supported, but va_list positions can be copied by assignment.
  +
* The printf length modifier for size_t is "I" instead of C99's "z".
  +
* inttypes.h is not supported. The length modifiers "I32" and "I64" can be used for 32-bit and 64-bit types.
   
 
* Mixed declarations and code (declarations after statements) is not supported.
  
* Mixed declarations and code (declarations after statements) is not supported.
Line 71: Line 89:
 
| no
  
| no
 
|}
  
|}
  +
  +
2016-01-07 update: OS X 10.9 has IP_PKTINFO and IPV6_RECVPKTINFO. NetBSD added IP_PKTINFO in 2013. FreeBSD still does not implement IP_PKTINFO, but implements an alternative using IP_RECVDSTADDR and IP_SENDSRCADDR. OS X 10.6 appears to have IP_RECVDSTADDR but not IP_SENDSRCADDR; it is not clear if it is possible in 10.6 to specify the from address when sending UDP messages.
  +
  +
== Leap second handling ==
  +
  +
* [[Leap second handling]]
   
 
[[Category:Lore]]
  
[[Category:Lore]]

Latest revision as of 19:48, 17 November 2019

This page collects some research we have done into the portability of various platform features. See Portability assumptions for the assumptions we make about target platforms based on this and other knowledge.

Mixed Windows C Runtimes and malloc/free

While Unix-like platforms implement C library functions in a central library which is usually dynamically linked, on Windows these functions are implemented in a "C Runtime" (CRT) library provided by the compiler. Even if all DLLs and the application are compiled using Visual Studio, multiple versions of the CRT may be present within the same process. Compiler flags (particularly the debugging flag) can affect which CRT is used by a library or application, so multiple versions can be present.

http://siomsystems.com/mixing-visual-studio-versions/ describes some of the incompatibilities which may arise from mixing CRT versions. They include three categories:

1. Receiving a pointer from malloc() from one CRT and freeing it with free() from another CRT can cause heap corruption. This problem is eliminated if all CRTs come from Visual Studio 2010 or later, as malloc() simply calls HeapAlloc() with the default process heap.

2. Objects such as FILE handles may be incompatible in different versions of the CRT, although no concrete examples of incompatibilities are known.

3. Static data held by the CRT will have one instance per version of the CRT. In particular, calls to setenv() from one CRT will not be reflected by getenv() from another ([krbdev.mit.edu #2636]).

Although problem 1 will become less important as older versions of Visual Studio age out, our library APIs are careful to provide free functions such as krb5_free_unparsed_name() to match allocation functions. Our plugin APIs are not always as careful, but many of them are currently not used in the Windows build.

C99 Compiler Support

[This section should be updated to reflect that Visual Studio 2013 is required for the Windows build. Significantly more C99 features are supported by this version.]

Full C99 support is common in compilers for modern Unix-like platforms, but is not present in Microsoft Visual C (see this blog post). Some C99 features are supported in MSVC; here is a partial list of supported and unsupported features based on experimenting with version 7.1 of the SDK:

  • The // comment syntax is supported.
  • Variadic macros are supported.
  • The "long long int" type is supported, as is the printf length modifier "ll".
  • stdint.h is supported.
  • Non-constant aggregate initializers of automatic variables are supported.
  • inline functions are supported, but the keyword is __inline.
  • MSVC defines __FUNCTION__ instead of C99's __func__.
  • va_copy is not supported, but va_list positions can be copied by assignment.
  • The printf length modifier for size_t is "I" instead of C99's "z".
  • inttypes.h is not supported. The length modifiers "I32" and "I64" can be used for 32-bit and 64-bit types.
  • Mixed declarations and code (declarations after statements) is not supported.
  • Named structure initializers are not supported.
  • Variable length arrays are not supported.
  • stdbool.h is not supported.

IPv4 and IPv6 pktinfo support

The basic BSD sockets API does not allow discovery of the interface address on which data was received, or control over the interface address used to send data. This makes it difficult to implement a UDP server which cooperates with NATs. Where available, we use an extension which allows this discovery and control. This extension was originally defined in RFC 2292 for the IPv6 socket API, and was revised in RFC 3542. Some platforms provide analagous support for IPv4.

The following table was collected in a platform survey to determine the prevalence of pktinfo support:

Platform RFC 2292 (IPV6_PKTINFO) RFC 3542 (IPV6_RECVPKTINFO) IPv4 pktinfo
Linux 2.6.32 yes yes yes
Solaris 10 yes yes no
Solaris 11 yes yes yes
FreeBSD 8.1-1 yes yes no
Hurd-0.3 yes no no
OSX (unknown version) yes no no
AIX 6.1 yes yes no
HP-UX B.11.11 yes yes no

2016-01-07 update: OS X 10.9 has IP_PKTINFO and IPV6_RECVPKTINFO. NetBSD added IP_PKTINFO in 2013. FreeBSD still does not implement IP_PKTINFO, but implements an alternative using IP_RECVDSTADDR and IP_SENDSRCADDR. OS X 10.6 appears to have IP_RECVDSTADDR but not IP_SENDSRCADDR; it is not clear if it is possible in 10.6 to specify the from address when sending UDP messages.

Leap second handling

Retrieved from "https://k5wiki.kerberos.org/wiki?title=Portability_research&oldid=5987"