General Information

This section provides general information such as behavior changes in Solaris 10 OS.

Single UNIX Specification, Version 3 Introduces Changes

The Single UNIX Specification, Version 3 (SUSv3) provides updates to the following POSIX operating system interfaces:

• POSIX.1-1990

• POSIX.1b-1993

• POSIX.1c-1996

• POSIX.2-1992

• POSIX.2a-1992

The updates include the following changes:

ENV Variable in Korn Shell

The environment variable ENV is no longer expanded in a noninteractive Korn shell. This change applies to both /bin/ksh and /usr/xpg4/bin/sh.

Compilers and SUSv3 Applications

Applications that conform to SUSv3 and other standards should be built by using correct feature test macros, compilers, and options. See the standards(5) man page.

file Command

When used with the -m option, the file command performs signed comparisons on user-defined magic files. Additionally, in the x86 environment, the command no longer switches multibyte integers to big-endian (SPARC) order before comparing the magic values. See the file(1) and magic(4) man pages.

Print Functions

snprintf() and vsnprintf() now return the number of bytes that would be formatted when the input value n=0. See the snprintf(3C) and vsnprintf(3C) man pages.

Text Editor

The editor checks for additional conditions before reading the .exrc files in $HOME or the current directory at startup. See the ex(1) and vi(1) man pages.

64-bit SPARC: Time Functions

If the input time_t is too large to be represented in a tm struct, the following functions return a null pointer and set errno to EOVERFLOW:

• gmtime()

• gmtime_r()

• localtime()

• localtime_r()

See the gmtime(3C), gmtime_r(3C), localtime(3C), and localtime_r(3C) man pages.

Trailing Slashes

SUSv3 allows a trailing slash character (/) in a path name only if the path specifies an existing directory or a directory to be created.

Utilities in /usr/xpg6/bin and /usr/xpg4/bin

Utilities in /usr/xpg6/bin and /usr/xpg4/bin have SUSv3-conforming or XPG4-conforming behavior that conflicts with default Solaris behavior. PATH must be properly configured for a user to use a command-line environment that conforms to SUSv3. See the man page for the specific utility for more information.

Support for TCP Wrappers is Enabled in sendmail

The utility sendmail has been added to the list of services that support TCP wrappers. The utility's added capability might cause sendmail to reject connections in Solaris 10 systems that were previously configured with very restrictive services. Use the daemon name sendmail to enable use of TCP wrappers. For information about TCP wrapper support, see sendmail Version 8.12 Uses TCP Wrappers in Solaris 10 What’s New. For information about configuring TCP wrappers, refer to the tcpd(1M) and hosts_access(4) man pages packaged in SUNWtcpd.

x86: Change to Solaris fdisk Identifier

In the Solaris 10 release, the Solaris fdisk identifier is set to 0xbf to facilitate the configuration of multiboot environments that include the Linux operating system. In previous Solaris releases, the Solaris fdisk identifier was set to 0x82, the same identifier as the Linux swap partition. The change to the identifier enables you to install the Solaris 10 OS and the Linux operating system without having to modify the Linux swap partition or reinstall the Linux OS.

The Solaris OS continues to recognize and support Solaris fdisk with the 0x82 identifier. You can use the fdisk command to switch between the 0x82 identifier and the 0xbf identifier. If you are using Solaris Live Upgrade and need to use the 0x82 identifier, the luactivate command enables you to switch the 0xbf identifier to the 0x82 identifier.

For more information, see the fdisk(1M) man page.

x86: Application Memory-Allocation Limits on x86 Systems

Solaris applications allocate memory by using functions like malloc(), brk(), or mmap(). The maximum amount of memory an application can allocate is bounded by the size of the user virtual address space. Program text, stack, data, and libraries that are contained within the user virtual address space can further reduce the maximum memory-allocation size.

32-bit Computing Environment

In a 32-bit computing environment, the 32-bit virtual address space is shared between user and kernel. Consequently, the size of the user virtual address space is 4 Gbytes minus the size of the kernel virtual address space. The configuration of the size of the kernel virtual address space depends on the size of physical memory. As the size of physical memory increases, the size of the user address space decreases. For systems with 8 Gbytes of memory, the size of the user address space is approximately 3 Gbytes.

If the memory allocation limits are insufficient for an application, two options exist:

• Reduce the default size of the kernel virtual address space to increase the size of the user virtual address space. You can set the kernelbase variable to a higher value by using the eeprom command. Exercise caution when changing kernelbase. Otherwise, a system with a smaller kernel virtual address space might hang or might not run as efficiently.

• As a better alternative, run the application in the Solaris x86 64-bit computing environment.

64-bit Computing Environment

In the 64-bit computing environment, the virtual address space for 32-bit applications is entirely for the user. Therefore, a 32-bit application can allocate the full 4 Gbytes minus the user address space that is needed for text, stack, and libraries.

On some early 64-bit AMD processors, the memory allocation limit can be further reduced by 1 Gbyte. To determine whether your processor is affected, perform the following steps:

1. Run the command pmap $$ from any 32-bit shell.

2. On the process map, check if addresses greater than or equal to 0xC0000000 are listed. If these addresses do not exist, then the Solaris OS has limited 32-bit applications to the lowest 3 Gbytes of the 4-Gbyte virtual address range.

A 64-bit application can allocate 250 Tbytes of memory depending on what the application already has in use.

x86: Solaris Supports the no execute Bit

Solaris 10 on x86 supports the no execute (NX) bit in 32-bit and 64-bit modes. The NX bit enables fully implementing the protections that are implied by not using PROT_EXEC in various memory system calls such as the mmap() function. Previously on x86, all mapped memory implicitly had PROT_EXEC set. With Solaris support for the NX bit, virus protection is enhanced.

On NX-capable hardware, Solaris OS uses the NX bit by default whenever PROT_EXEC is not specified. Stack segments, however, use PROT_EXEC by default, not the NX bit. The default setting for stack segments can be changed by performing one of the following:

• Set no_exec_userstack in /etc/system to globally set no exec on all applications stacks.

• Link an individual application with the /usr/lib/ld/map.noexstk map file.

The system administrator can disable all use of the NX bit by using the eeprom command to set enforce-prot-exec to “off”. This variable is provided as a transition workaround for any system with legacy applications that are missing PROT_EXEC.