The Linux Standard Base Specification 2.0.1 for libc places constraints on the arguments to some internal functions [1]. If the constraints are not met, the behavior of the functions is not defined.


The value 1 must be passed to the first parameter (the version number) of the following file system function:

	__xmknod

The value 2 must be passed to the third parameter (the group argument) of the following wide character string functions:

__wcstod_internal
__wcstof_internal
_wcstol_internal
__wcstold_internal
__wcstoul_internal

The value 3 must be passed as the first parameter (the version number) of the following file system functions:

__xstat
__lxstat
__fxstat
__xstat64
__lxstat64
__fxstat64

Depending on the specific C compiler in use, the address of a system FILE object might be significant to the use of the FILE object as a stream. Using a copy of the FILE object without the associated address can lead to undefined behavior resulting in potential system information leakage, a system crash, or the ability for a malicious actor to read or edit files at their discretion.

Example 1: The following code shows a system FILE object that is dereferenced and copied by value.

FILE *sysfile = fopen(test.file, "w+");
FILE insecureFile = *sysfile;

Because sysfile is dereferenced in the assignment of insecureFile, use of insecureFile can result in a wide variety of problems.

Performing file operations on a system FILE object after its associated stream is closed results in undefined behavior. Depending on the specific C compiler in use, the file operation can cause a system crash or even potentially result in modification or reading of the same or different file.

Example 1: The following code shows an attempt to read a system FILE object after the corresponding stream is closed.

FILE *sysfile = fopen(test.file, "r+");
res = fclose(sysfile);
if(res == 0){
    printf("%c", getc(sysfile));    
}

Because the getc() function runs after the file stream for sysfile is closed, getc() results in undefined behavior and can cause a system crash or potential modification or reading of the same or different file.

Deleting a managed pointer will cause the program to crash or otherwise do the wrong thing when, later on, the pointer management code assumes that the pointer is still valid. The following example illustrates the error.

  std::auto_ptr<foo> p(new foo);
  foo* rawFoo = p.get();
  delete rawFoo;

The only exception to this rule comes when a managed pointer class supports a "detach" operation allowing the programmer to take control of memory management for the given pointer. If the program detaches the pointer from the management class before calling delete, the management class knows not to use the pointer any further.