La función de Solidity assert está destinada a verificar solo declaraciones que se evalúan como true. Si una declaración false pasa a esta función, ello indica que el código no funciona correctamente o que la función se está utilizando incorrectamente, por ejemplo, para validar entradas.

Ejemplo 1: El siguiente código utiliza la función assert para comprobar una declaración falsa.

contract A {
    B b = new B(7);

    function checkWithAssert(){
        assert(b.retValue() == 21);
        ...
    }

}

contract B {
    uint _par;
    constructor(uint par){
        _par = par;
    }

    function retValue() returns(uint){
        return _par;
    }
}

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 usará para definir campos Serializable porque no es private, static ni 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);
}