Este campo ha sido anotado con FortifyNonZero, que se usa para indicar que cero no es un valor permitido.

Esta expresión siempre será no nula porque hace referencia a un puntero de función más que al valor devuelto de la función.

Ejemplo 1: la condicional siguiente nunca se disparará. El predicado getChunk == NULL siempre será falso porque getChunk es el nombre de una función definida en el programa.

  if (getChunk == NULL)
    return ERR;

Como las variables locales están asignadas en la pila, cuando un programa devuelve un puntero a una variable local, se devuelve una dirección de pila. Es probable que la siguiente llamada de función vuelva a utilizar esta misma dirección de pila y, por lo tanto, sobrescriba el valor del puntero, que ya no corresponde a la misma variable porque el marco de pila de una función queda invalidado cuando vuelve. En el mejor de los casos, esto provocará que el valor del puntero cambie de forma inesperada. En muchos casos provoca el bloqueo del programa la próxima vez que se desreferencia el puntero. El problema puede ser difícil de depurar porque la causa del mismo a menudo está muy alejada del síntoma.

Ejemplo 1: la función siguiente devuelve una dirección de pila.

char* getName() {
  char name[STR_MAX];
  fillInName(name);
  return name;
}

Por definición, no es posible anular los métodos estáticos, ya que pertenecen a la clase más que a una instancia de la clase. Sin embargo, hay casos en los que parece que el método estático se anuló en una subclase, lo que podría provocar confusión y que se llamase a la versión incorrecta del método.

Ejemplo 1: el siguiente ejemplo intenta definir una API para autenticar a los usuarios.

class AccessLevel{
  public static final int ROOT = 0;
  //...
  public static final int NONE = 9;
}
//...
class User {
  private static int access;
  public User(){
    access = AccessLevel.ROOT;
  }
  public static int getAccessLevel(){
    return access;
  }
  //...
}
class RegularUser extends User {
  private static int access;
  public RegularUser(){
    access = AccessLevel.NONE;
  }
  public static int getAccessLevel(){
    return access;
  }
  public static void escalatePrivilege(){
    access = AccessLevel.ROOT;
  }
  //...
}
//...
class SecureArea {
  //...
  public static void doRestrictedOperation(User user){
    if (user instanceof RegularUser){
      if (user.getAccessLevel() == AccessLevel.ROOT){
        System.out.println("doing a privileged operation");
      }else{
        throw new RuntimeException();
      }
    }
  }
}

A primera vista, parece que el código está bien. Sin embargo, como estamos llamando al método getAccessLevel() en la instancia user y no en las clases User o RegularUser, la condición siempre devolverá true y se llevará a cabo la operación restringida aunque se utilice instanceof para entrar en esta parte del bloque if/else.

La especificación de serialización de objetos Java permite que los desarrolladores definan manualmente los campos serializables para una clase en la matriz serialPersistentFields. Esta característica solo funcionará si serialPersistentFields se declara como private, static y final.

Ejemplo 1: La siguiente declaración de serialPersistentFields no se utilizará para definir campos Serializable porque no es private, static y final.

class List implements Serializable {
public ObjectStreamField[] serialPersistentFields = { new ObjectStreamField("myField", List.class) };
...
}

Llamar a Object.equals() en una matriz es casi siempre un error, ya que comprobará la igualdad de las direcciones de las matrices, en vez de la igualdad de los elementos de las matrices, y debería reemplazarse por java.util.Arrays.equals().

Ejemplo 1: el siguiente ejemplo intenta comprobar dos matrices utilizando la función Object.equals().

...
  int[] arr1 = new int[10];
  int[] arr2 = new int[10];
  ...
  if (arr1.equals(arr2)){
    //treat arrays as if identical elements
  }
...

Esto casi siempre resultará en código que nunca se ejecuta, a menos que en algún momento se asigne una matriz a otra.

Algunas familias de funciones se implementan como funciones en algunas plataformas y como macros en otras. Si las funciones se basan en un recurso compartido que se mantiene de forma interna en lugar de transferirse cuando se invoca, deben usarse en el mismo ámbito del programa, porque de otro modo el recurso compartido será inaccesible.

Ejemplo 1: el código siguiente usa pthread_cleanup_push() para insertar la función routine en las devoluciones y la pila de limpieza del subproceso de llamada. Como pthread_cleanup_push() y su función asociada pthread_cleanup_pop() se implementan como macros en las plataformas que no son IBM AIX, la estructura de datos creada por pthread_cleanup_push() no será accesible para las subsiguientes llamadas a pthread_cleanup_pop(). El código no se compilará o se comportará incorrectamente en tiempo de ejecución en todas las plataformas donde estas funciones se implementen como macros.

void helper() {
   ...
   pthread_cleanup_push (routine, arg);
}

No desasigne de forma explícita la memoria de pila. Una función que defina el búfer de una pila desasignará automáticamente el búfer cuando la función vuelva.
Ejemplo 1:

void clean_up()
{
    char tmp[256];
    ...
    free(tmp);
    return;
}

La liberación explícita de la memoria de pila puede dañar las estructuras de datos de asignación de memoria. Puede llevar a la finalización anómala del programa o dañar más datos.

El nombre de este método es similar al nombre del método habitual de Java, pero se ha escrito incorrectamente o la lista de argumentos provoca que no se reemplace al método previsto.

Ejemplo 1: el siguiente método está diseñado para reemplazar Object.equals():

public boolean equals(Object obj1, Object obj2) {
  ...
}

Como Object.equals() toma solo un argumento, el método en el Example 1 no se llama nunca.

El tiempo de ejecución de .NET permite la serialización de cualquier objeto que declare el atributo [Serializable]. Si la clase se puede serializar mediante los métodos de serialización predeterminados definidos por .NET Framework, esto es necesario y suficiente para que el objeto se serialice correctamente. Si la clase requiere métodos de serialización personalizados, debe implementar también la interfaz ISerializable. Sin embargo, la clase debe declarar aún el atributo [Serializable].

Ejemplo 1: la clase CustomStorage implementa la interfaz ISerializable. Sin embargo, debido a que no puede declarar el atributo [Serializable], no se serializará.

public class CustomStorage: ISerializable {
	...
}

La serialización de las clases internas supone la serialización de la clase externa y puede que se filtre información o se produzca un error en el tiempo de ejecución si no es posible serializar la clase externa. Además, la serialización de las clases internas puede causar dependencias de la plataforma, ya que el compilador Java crea campos sintéticos para implementar las clases internas, pero dichos campos dependen de la implementación y varían en función del compilador.

Ejemplo 1: el siguiente código permite la serialización de una clase interna.

  ...
  class User implements Serializable {
    private int accessLevel;
    class Registrator implements Serializable {
      ...
    }
  }

En el Example 1, cuando se serializa la clase interna Registrator, también se serializa el campo accessLevel de la clase externa User.

Una clase principal declara el método synchronized, garantizando un comportamiento correcto cuando varios subprocesos acceden a la misma instancia. Todos los métodos de reemplazo también deben ser declarados como synchronized porque, de no ser así, podría producirse un comportamiento inesperado.

Ejemplo 1: en el código siguiente, la clase Foo reemplaza a la clase Bar, pero no declara el método synchronizedMethod para que sea synchronized:

public class Bar {
public synchronized void synchronizedMethod() {
    for (int i=0; i<10; i++) System.out.print(i);
    System.out.println();
}
}

public class Foo extends Bar {
public void synchronizedMethod() {
    for (int i=0; i<10; i++) System.out.print(i);
    System.out.println();
}
}

En este caso, se podría convertir una instancia de Foo en el tipo Bar. Si se da la misma instancia a dos subprocesos distintos y synchronizedMethod se ejecuta repetidamente, el comportamiento se impredecible.

El programa utiliza el método equals() para comparar un objeto con null. Esta comparación siempre devolverá false, porque el objeto no es null. (Si el objeto es null, el programa lanzará una NullPointerException).

Los subprocesos generados al llamar pthread_create() desde la función main() del proceso primario finalizarán antes de tiempo si el proceso primario termina la ejecución antes que cualquier subproceso que haya generado sin llamar pthread_exit(). Llamar pthread_exit() garantiza que el proceso primario se mantendrá activo hasta que todos sus subprocesos hayan finalizado la ejecución. Otra opción es que el proceso primario puede llamar pthread_join en todos los subprocesos secundarios y garantizar su compleción antes de que el proceso concluya.

Ejemplo 1: el código siguiente utiliza pthread_create() para crear un subproceso y, a continuación, sale normalmente. Si el subproceso secundario no ha completado su ejecución hasta que la función main() vuelve, entonces finalizará antes de tiempo.

void *Simple(void *threadid)
{
   ...
   pthread_exit(NULL);
}

int main(int argc, char *argv[]) {
   int rc;
   pthread_t pt;
   rc = pthread_create(&pt, NULL, Simple, (void *)t);
   if (rc){
     exit(-1);
   }
}

Durante la deserialización, readObject() actúa como un constructor, por lo que la inicialización del objeto no se completa hasta que finaliza esta función. Así, cuando una función readObject() de una clase Serializable llama a una función que se puede sobrescribir, puede permitir que el método de sobrescritura acceda al estado del objeto antes de que se inicialice por completo.

Ejemplo 1: la siguiente función readObject() llama a un método que se puede sobrescribir.

  ...
  private void readObject(final ObjectInputStream ois) throws IOException, ClassNotFoundException {
    checkStream(ois);
    ois.defaultReadObject();
  }

  public void checkStream(ObjectInputStream stream){
    ...
  }

Como la función checkStream() y su clase envolvente no son final y públicas, la función se puede sobrescribir y un atacante puede sobrescribir la función checkStream() para tener acceso al objeto durante la deserialización.

Devolver una variable de lista private readonly desde una propiedad de solo getter permite que el código de llamada modifique el contenido de la lista, lo cual proporciona a la lista acceso de escritura y contradice las intenciones del programador que la hizo private readonly.

Ejemplo 1: el siguiente código contiene una lista _item declarada como private readonly.

       class Order
      {
          private readonly List<string> _item = new List<string>();
          public IEnumerable<string> Item { get { return _item; } }
          
          public Order()
          {
              /*class initialize            */
          }

          /*some important function......*/
      }
    

El uso de la recursividad es un elemento básico para crear y administrar estructuras de datos vinculados. La recursividad también corre el riesgo de procesarse indefinidamente si los datos incorporan un enlace circular, que a su vez agotará la pila y bloqueará el programa.

Ejemplo 1: El siguiente fragmento de código demuestra esta vulnerabilidad con Apache Log4j2.

Marker child = MarkerManager.getMarker("child");
Marker parent = MarkerManager.getMarker("parent");

child.addParents(parent);
parent.addParents(child); 
        
String toInfinity = child.toString();

Cuando el elemento secundario llama a toString(), que incluye un método de procesamiento recursivo, desencadena una excepción de desbordamiento de pila (agotamiento de pila). Esta excepción se produce debido al enlace circular entre elemento secundario y elemento principal.

Para comparar un valor de punto flotante con un objeto String, es necesario cambiarlo primero por un objeto String, por lo general, mediante una función como Double.toString(). En función de la forma y el valor de la variable de punto flotante, al convertirla en un objeto String, puede ser "NaN", "Infinity" o "-Infinity", incluir alguna cantidad de decimales finales con ceros o contener un campo de exponente. Si se convierte en una cadena hexadecimal, la representación también podría diferir en gran medida.

Ejemplo 1: el siguiente ejemplo compara una variable de punto flotante con una String.

  ...
  int initialNum = 1;
  ...
  String resultString = Double.valueOf(initialNum/10000.0).toString();
  if (s.equals("0.0001")){
    //do something
    ...
  }
  ...

Base de datos SQL de Windows Azure solo admite la autenticación de SQL Server. No se admite autenticación de Windows (seguridad integrada). Los usuarios deben proporcionar credenciales (nombre de usuario y contraseña) cada vez que se conecten a Base de datos SQL de Windows Azure. Según las directrices y limitaciones generales de Base de datos SQL de Microsoft Windows Azure, no están disponibles los siguientes nombres de cuentas: admin, administrador, invitado, raíz, sa.

El código adyacente imposibilita la ejecución de esta instrucción.

Ejemplo 1: Es imposible cumplir la condición para la segunda instrucción if. Exige que la variable s sea no nula, mientras que en la única ruta de acceso en la que a s se le puede asignar un valor no nulo hay una instrucción return.

String s = null;

if (b) {
   s = "Yes";
   return;
}

if (s != null) {
   Dead();
}