Esse campo foi anotado com FortifyNonZero, que é usado para indicar que zero não é um valor permitido.

Essa expressão sempre será nula, pois faz referência a um ponteiro de função, e não ao valor de retorno da função.

Exemplo 1: A seguir condição nunca será disparada. O predicado getChunk == NULL sempre será "false", pois getChunk é o nome de uma função definida no programa.

  if (getChunk == NULL)
    return ERR;

Como variáveis locais são alocadas na pilha, quando um programa retorna um ponteiro para uma variável local, ele está retornando um endereço de pilha. Uma chamada de função subsequente provavelmente reutilizará esse mesmo endereço de pilha, substituindo assim o valor do ponteiro, que já não corresponde à mesma variável uma vez que a estrutura de pilha de uma função é invalidada quando esta é retornada. Na melhor das hipóteses, isso fará com que o valor do ponteiro mude inesperadamente. Em muitos casos, isso faz com que o programa trave da próxima vez em que ocorrer a desreferência ao ponteiro. O problema pode ser difícil de depurar, pois a sua causa está muitas vezes bem distante do sintoma.

Exemplo 1: A função a seguir retorna um endereço de pilha.

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

Métodos estáticos não podem ser substituídos por definição, uma vez que pertencem à classe e não a uma instância da classe. Mesmo assim, existem casos em que parece que um método estático foi substituído em uma subclasse, o que pode causar confusão e fazer com que uma versão incorreta do método seja chamada.

Exemplo 1: O exemplo a seguir tenta definir uma API para a autenticação de usuários.

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();
      }
    }
  }
}

À primeira vista, esse código parece bom. No entanto, como estamos chamando o método getAccessLevel() em relação à instância user, e não contra as classes User ou RegularUser, isso significa que essa condição sempre retornará true e a operação restrita será realizada mesmo que instanceof tenha sido usado para entrar nessa parte do bloco if/else.

A Especificação de Serialização de Objeto Java permite que os desenvolvedores definam manualmente campos Serializáveis para uma classe especificando-os na matriz serialPersistentFields. Esse recurso somente funcionará se serialPersistentFields for declarado como private, static e final.

Exemplo 1: A seguinte declaração de serialPersistentFields não será usada para definir campos Serializable porque não é private, static e final.

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

Chamar Object.equals() contra um array é um erro na maioria dos casos, pois isso verificará a igualdade dos endereços dos arrays, em vez da igualdade dos elementos dos arrays, e, em geral, deve ser substituído por java.util.Arrays.equals().

Exemplo 1: O exemplo a seguir tenta verificar dois arrays utilizando a função Object.equals().

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

Isso quase sempre resultará em um código que nunca é executado, a menos que, em algum momento, houver uma atribuição de um array ao outro.

Certas famílias de funções são implementadas como funções em algumas plataformas e como macros em outras. Se as funções dependerem de um recurso compartilhado que é mantido internamente em vez de ser transmitido quando elas são invocadas, essas funções deverão ser usadas no mesmo escopo de programa, caso contrário, o recurso compartilhado será inacessível.

Exemplo 1: O código a seguir usa pthread_cleanup_push() a fim de enviar a função routine para a pilha de limpeza do thread de chamada e, em seguida, é retornado. Como pthread_cleanup_push() e sua função parceira pthread_cleanup_pop() são implementadas como macros em plataformas diferentes do IBM AIX, a estrutura de dados criada por pthread_cleanup_push() não será acessível a chamadas subsequentes para pthread_cleanup_pop(). O código não conseguirá compilar ou apresentará um comportamento incorreto em tempo de execução em todas as plataformas nas quais essas funções são implementadas como macros.

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

Não desaloque explicitamente a memória da pilha. Uma função que define um buffer de pilha desalocará automaticamente o buffer quando for retornada.
Exemplo 1:

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

A liberação explícita de memória pode corromper estruturas de dados de alocação de memória. Isso pode levar ao encerramento anormal do programa ou a maiores corrupções de dados.

O nome desse método é semelhante a um nome de método Java comum, mas está escrito incorretamente ou a lista de argumentos faz com que ele não substitua o método pretendido.

Exemplo 1: O método a seguir tem o objetivo de substituir Object.equals():

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

Porém, como Object.equals() usa apenas um argumento, o método no Example 1 nunca é chamado.

O tempo de execução .NET permitirá a serialização de qualquer objeto que declare o atributo [Serializable]. Se a classe puder ser serializada usando os métodos de serialização padrão definidos pelo .NET Framework, será necessário e suficiente que o objeto seja serializado corretamente. Se a classe exigir métodos de serialização personalizados, ela também deverá implementar a interface ISerializable. No entanto, a classe ainda deve declarar o atributo [Serializable].

Exemplo 1: A classe CustomStorage implementa a interface ISerializable. No entanto, por não declarar o atributo [Serializable], ela não será serializada.

public class CustomStorage: ISerializable {
	...
}

A serialização de classes internas resulta na serialização da classe externa, o que pode deixar vazar informações ou provocar erros de tempo de execução se a classe externa não for serializável. Além disso, a serialização de classes internas pode causar dependências de plataforma, já que o compilador Java cria campos sintéticos para implementar classes internas, mas estas são dependentes da implementação e podem variar de um compilador para outro.

Exemplo 1: O código a seguir permite a serialização de uma classe interna.

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

No Example 1, quando a classe interna Registrator for serializada, ela também serializará o campo accessLevel da classe externa User.

Uma classe pai declarou o método synchronized, garantindo o comportamento correto quando vários threads acessam a mesma instância. Todos os métodos de substituição também devem ser declarados como synchronized, caso contrário, um comportamento inesperado poderá ocorrer.

Exemplo 1: No código a seguir, a classe Foo substitui a classe Bar, mas não declara o método synchronizedMethod como 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();
}
}

Nesse caso, uma instância de Foo pode ser convertida no tipo Bar. Se a mesma instância for fornecida a dois threads separados e synchronizedMethod for executado repetidamente, o comportamento será imprevisível.

O programa usa o método equals() para comparar um objeto com null. Essa comparação sempre retornará "false", uma vez que o objeto não é null. (Se o objeto for null, o programa lançará NullPointerException).

Threads gerados ao chamar pthread_create() a partir da função main() do processo pai serão encerrados prematuramente se o processo pai encerrar sua execução antes dos threads que ele gerou, sem chamar pthread_exit(). Chamar pthread_exit() garante que o processo pai permanecerá ativo até que a execução de todos os seus threads tenha sido encerrada. Como alternativa, o processo pai pode chamar pthread_join em todos os threads filho e garantir que eles serão concluídos antes da conclusão do processo.

Exemplo 1: O código a seguir usa pthread_create() para criar um thread e depois é encerrado normalmente. Se a conclusão do thread filho não tiver sido encerrada até o retorno da função main(), o thread será encerrado prematuramente.

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 a desserialização, readObject() age como um construtor e, portanto, a inicialização do objeto só estará concluída quando essa função terminar. Portanto, quando uma função readObject() de uma classe Serializable chama uma função substituível, isso pode fornecer ao método de substituição o acesso necessário ao estado do objeto antes que ele seja totalmente inicializado.

Exemplo 1: A função readObject() a seguir chama um método que pode ser substituído.

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

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

Como a função checkStream() e sua classe delimitadora não são final e públicas, isso implica que a função pode ser substituída, o que pode significar que um invasor pode substituir a função checkStream() a fim de obter acesso ao objeto durante a desserialização.

Retornar uma variável de lista private readonly de uma propriedade somente "getter" permite que o código de chamada modifique o conteúdo da lista, fornecendo a ela eficazmente acesso de gravação e contrariando as intenções do programador que a tornou private readonly.

Exemplo 1: O código a seguir contém uma lista _item, que é 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......*/
      }
    

O uso da recursão é um elemento básico para criar e gerenciar estruturas de dados vinculadas. A recursão também correrá o risco de processar indefinidamente se os dados incorporarem um link circular, que, por sua vez, esgotará a pilha e travará o programa.

Exemplo 1: O trecho de código a seguir demonstra essa vulnerabilidade usando o Apache Log4j2.

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

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

Quando o filho chama toString(), que inclui um método de processamento recursivo, ele aciona uma exceção de estouro de pilha (exaustão de pilha). Essa exceção ocorre devido ao link circular entre filho e pai.

Para comparar um valor de ponto flutuante com um objeto String, ele primeiro deve ser transformado em um objeto String, o que normalmente é feito usando uma função como Double.toString(). Dependendo do tipo e do valor da variável de ponto flutuante, quando convertida em um objeto String, ela pode ser "NaN", "Infinity", "-Infinity", ter uma certa quantidade de casas decimais à esquerda contendo zeros ou incluir uma campo de expoente. Se convertida em uma String hexadecimal, a representação também poderá ser consideravelmente diferente.

Exemplo 1: O exemplo a seguir compara a variável de ponto flutuante com uma String.

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

O Banco de dados SQL do Windows Azure dá suporte apenas à autenticação do SQL Server. A autenticação do Windows (segurança integrada) não tem suporte. Os usuários devem fornecer credenciais (login e senha) cada vez que se conectarem ao banco de dados SQL do Windows Azure. De acordo com as diretrizes e limitações gerais do banco de dados SQL do Microsoft Windows Azure, estes nomes de contas não estão disponíveis: admin, administrador, convidado, raiz, sa.

O código circundante torna impossível que essa instrução seja executada.

Exemplo 1: A condição para a segunda instrução if é impossível de atender. Ela requer que a variável s seja não nula, embora no único caminho em que s pode receber um valor não nulo exista uma instrução return.

String s = null;

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

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