Bugs mais comuns do tipo "Y2K" hoje em dia? [fechadas]

40

Eu não quero dizer especificamente problemas relacionados a datas como 2038, mas de forma mais geral, erros que se encaixam no padrão:

  • Uma geração atrás, os programadores tendiam a escrever código que ass-u-me-d X, o que era razoável na época.
  • Mas as circunstâncias mudaram e agora X é uma fonte comum de problemas que precisam ser corrigidos.

Por exemplo:

  • X="A memória é muito cara para justificar o armazenamento de todos os 4 dígitos do ano. Não se preocupe com o ano 2000, isso está muito distante." (quebrado por Y2K)
  • X="Quem precisa de size_t ? Podemos usar apenas unsigned int ". (quebrado por sistemas de 64 bits)
por dan04 29.03.2011 / 08:22
fonte

24 respostas

87

Apenas código de rede IPV4. O tempo ainda não chegou para a maioria das pessoas, mas a ideia de redes IPV4 só se tornará obsoleta.

    
por 29.03.2011 / 08:51
fonte
76

Muitos problemas de localização se encaixam nesse padrão:

  • há uma geração, os programadores assumiram que todos os caracteres podem ser representados com um tipo de dados de 8 bits
  • há uma geração, os programadores presumiram que todo tipo de texto deveria ser lido da esquerda para a direita, de cima para baixo
  • há uma geração, os programadores assumiram que o separador de campo em um arquivo CSV é sempre o caractere de vírgula , (Não, na verdade não é. CSV é a extensão do arquivo, não a especificação do formato do arquivo. CSV foi inventado, na verdade era apenas valores separados por vírgula. À medida que evoluía, ninguém queria renomeá-lo para "arquivo de dados tabular com separador de coluna dependente de código de idioma, campos citados para valores de campo contendo um caractere separador aspas duplas para caracteres de aspas ".)
por 29.03.2011 / 14:42
fonte
41

Validadores para nomes de domínio que fazem suposições erradas, como:

  • O TLD tem 2 ou 3 caracteres (não é verdade desde 2001);
  • nomes de domínio e TLDs contêm apenas caracteres US-ASCII (não são verdadeiros desde janeiro de 2010);
por 29.03.2011 / 13:38
fonte
35

Eu fiz algumas pesquisas sobre y2010 cerca de 14 meses atrás:

printf("200%d", year);

Acredite ou não, existe um código como esse.

    
por 29.03.2011 / 11:12
fonte
26

Outro que ainda não foi abordado são aplicativos (e especialmente sites), assumindo que todos os endereços sejam endereços dos EUA. Em uma era em que os negócios internacionais são cada vez mais vitais, isso está causando problemas. As empresas estão perdendo negócios possivelmente lucrativos porque os clientes se vêem incapazes de fazer pedidos.

Isso é especialmente crítico com códigos postais / CEPs e números de telefone. Diversas aplicações e sites validam essas informações contra o sistema dos EUA, assumindo incorretamente que esse é o único sistema existente (quando, na verdade, grande parte do planeta usa sistemas diferentes, e há países sem nenhum código postal). Um problema menor é exigir números de casas em endereços, quando ainda há locais sem eles (pequenas aldeias) e às vezes até nomes de ruas.

Ouvi uma história no ano passado sobre alguém em uma pequena vila na França tentando pedir uma linha de ajuda instalada (ele estava se mudando para lá) e achando impossível que o sistema computadorizado usado pelo provedor não aceitasse seu endereço que existia apenas do nome da casa e da aldeia (sem nome da rua, sem número da casa, sem código postal).

    
por 29.03.2011 / 15:06
fonte
21

Codificação de byte único (ASCII, ISO-8859-x) x codificação de múltiplos bytes (Unicode, UTF-8). Esse é atualmente o maior problema legado em que posso pensar. Há tantos softwares que assumem que o tamanho do byte das sequências = = comprimento do caractere.

    
por 29.03.2011 / 12:53
fonte
16

IPv4 vem à mente. Estamos ficando sem endereços IP (na verdade, já pode ter acabado, os últimos lotes foram distribuídos para autoridades regionais).

A introdução do IPv6 de substituição é lenta, pois os fabricantes de hardware e software estão se recuperando.

    
por 29.03.2011 / 09:43
fonte
15

Algo que me deixou muito mal alguns meses atrás foi a data de expiração do cookie ...

Aparentemente, as datas de expiração dos cookies podem ser definidas apenas até o futuro (me corrija se eu estiver errado neste ponto - não sou especialista nisso!). De qualquer forma, há alguns meses um problema de login realmente bizarro surgiu com um aplicativo que nossa equipe estava mantendo. Mas, este era um projeto paralelo, e esse componente de login era realmente sólido, não precisou ser tocado em 10 anos, então ninguém estava por perto que sabia como funcionava (nunca tinha que tocá-lo por quão sólido ele era) .

De qualquer forma - depois de meio dia pesquisando e perdendo a cabeça, notei que havia uma data codificada de 31 de dezembro de 2010 em uma rotina de validação. Então, basicamente, qualquer pessoa que estivesse tentando usar o sistema com um cookie mais novo não poderia efetuar login. Descobriu que esse era um código embutido em 2001, porque eles não podiam definir uma data de validade do cookie além de 10 anos no futuro - e o programador na época era muito preguiçoso para torná-lo uma "data flutuante".

    
por 29.03.2011 / 13:12
fonte
13

Fazendo qualquer tipo de aritmética de data (adição / subtração) diretamente em um número inteiro de horário do UNIX Epoch, por exemplo:

gmt_epoch
1301397219
March 29, 2011 11:13:39 GMT

e você quer descobrir o horário correto para a costa leste da América, EST (-5: 00 GMT), então você faz algo como:

gmt_epoch-(5*60*60)
1301379219
March 29, 2011 06:13:39 EST

que é ERRADO, porque 29 de março de 2011 é EDT (-4: 00 GMT).

Isso não é muito um erro de calibre do Y2K, já que você não precisa esperar 10 anos para ver o seu efeito, mas, digamos, contratar um programador de contrato que está trabalhando no projeto apenas por um mês, então, BAM! a coisa quebra depois que o horário de verão termina.

    
por 29.03.2011 / 13:23
fonte
12

Segurança.

Armazenando senhas sem hash, deixando "portas dos fundos" em aplicativos, usando idiomas com buffer overflow. Veja o OWASP top 10 para a lista atual de suposições idiotas.

    
por 29.03.2011 / 11:55
fonte
11

Suporte e uso de fuso horário. Quantos sistemas você viu que apenas têm dateStarted ou dateCreated sem qualquer reconhecimento ou notação em que fuso horário é considerado a base? Espero que seja GMT / UTC, mas contando com isso é arriscado na melhor das hipóteses.

    
por 29.03.2011 / 20:54
fonte
10

Desenvolvedores - ou DBAs - que assumem que o nome de todos se encaixa no padrão familiar (para os olhos ocidentais) de FirstName e LastName .

  • Em muitos países asiáticos, o nome da família tradicionalmente vem em primeiro lugar por causa de um valor cultural que coloca as necessidades da família acima das necessidades do indivíduo. Escrever "Bevan Arps" pode ser considerado desrespeitoso, até mesmo rude.

  • Em outras partes do mundo, as famílias não têm nomes - as pessoas são referidas por seu (único) nome. Se pode haver confusão, seus pais ou comércio também são referenciados. [<>> Aparte : Esta é também a fonte de muitos nomes de famílias ocidentais como McGreggor (filho de Greggor), Mathieson (filho de Mathie), O'Connor (filho de Connor), Carpenter, Smith, Butcher e Taylor.]

  • Nem todos os nomes têm uma ortografia longa - "N" e "O" são as grafias em inglês de nomes genuínos, mas muitos sistemas rejeitam os nomes como curtos demais.

  • Nem o sobrenome de todos é pequeno o suficiente para caber em um campo de 50 caracteres.

  • Nem o nome de todos é capitalizado da mesma maneira. Algumas pessoas escrevem seu sobrenome "van den ..." outros "Van Den ..." e ajustando está errado .

por 30.03.2011 / 10:16
fonte
10

No Reino Unido, quando a alíquota do IVA passou de 17,5% para 15% em dezembro de 2008, foi a primeira mudança para o IVA desde 1991 e muitos programas tiveram seu valor embutido.

A mudança também significou que o sistema teve que separar as taxas de IVA com base na data, porque não seria tão simples quanto alterar um valor constante em algum lugar.

Espero que estejam todos prontos quando voltarem (e depois aumentarem)!

    
por 30.03.2011 / 10:24
fonte
8

Uma suposição é que nosso negócio não terá que crescer para mercados fora dos EUA (nem de língua inglesa). A internacionalização, quando você fez tudo certo para começar, é um grande projeto. Quando a maioria de suas strings é codificada no código, é um projeto muito maior.

Há também suposições que as pessoas fazem em relação a idiomas.

Você pode converter livremente entre maiúsculas e minúsculas (quebrado em alemão, com o caractere eszet semelhante a beta convertendo em dois S maiúsculos).

Você tem formas singulares e plurais (algumas linguagens também têm formas duplas).

Um pressionamento de tecla sem modificador produz um caractere (um amigo meu foi atingido por um problema que ocorreu ao pressionar o ESC após digitar uma consoante para formar a primeira parte de uma sílaba japonesa, como katakana e hiragana são alfabetos sílabos).

    
por 29.03.2011 / 16:24
fonte
8

Não usando uma biblioteca XML para escrever XML.

O nível de frustração que você recebe ao lidar com arquivos XML malformados pode, às vezes, ser demais. print "<data>$value</data>"; provavelmente falhará.

Existem tantas bibliotecas XML por aí que você encontrará uma fácil de usar. Sério - pare de reinventar o que os outros já gastaram muitos recursos. Você pode pensar que sabe XML, mas mais coisas podem dar errado do que você pode esperar.

    
por 30.03.2011 / 02:54
fonte
7

A suposição do programador de que a localização geográfica de um usuário deve definir automaticamente o idioma preferido desse usuário. A tecnologia IP-to-location não deve ser usada para decisões de linguagem preferenciais .... nunca. Até o Google e o Facebook são culpados por isso.

    
por 29.03.2011 / 23:19
fonte
5

Usando um inteiro para armazenar moeda em sua menor forma. Diga cêntimos. Amanhã você pode usar uma nova moeda, isso aconteceu em muitos países europeus.

Armazenando taxas de IVA estáticas para categorias etc. em webstores. Em muitos países, as taxas de impostos são consideradas estáticas, mas a ideia não é tê-las estáticas e, de vez em quando, elas são alteradas.

Armazenar números cívicos em uma notação específica e usá-los como uma chave (ou qualquer outra coisa de "chave natural"); amanhã você pode ter milhões de refugiados da China, seu número cívico se parecerá com o seu? (Hoje isso já é o caso na Suécia)

Supondo que 0 seja NULL em bancos de dados. Em seguida, o padrão SQL pode começar a contar a partir de 0, quem sabe? : -)

    
por 30.03.2011 / 02:20
fonte
4

Estou feliz por não estar por perto para o apocalipse de Y10K.

    
por 29.03.2011 / 16:42
fonte
4

Supondo que uma chave primária derivada dos dados do aplicativo nunca precisará ser alterada. O exemplo mais comum é o ID do usuário - geralmente é impossível mudar, mesmo que o usuário mude o nome dele.

Outros exemplos que eu já vi - assumindo que os códigos de país nunca mudam, códigos de moeda, nomes de cidades.

    
por 30.03.2011 / 00:15
fonte
4

Processamento paralelo em série. Os processadores multicore são ou serão vistos em breve como universalmente onipresentes, com exceção do hardware específico para um produto ou uma tarefa.

    
por 30.03.2011 / 04:59
fonte
2

Bem, isso se encaixa nessa pergunta, eu acho.

Basicamente, redes WiFi não seguras. Aparentemente, as organizações de padrões de alguma forma pensaram em algo como "Oh, só os mocinhos vão usar redes WiFi abertas!", Então eles decidiram nunca criptografá-lo de qualquer forma. Quero dizer, esse não é o tipo de coisa para a qual a troca de chaves de criptografia Diffie-Hellman foi feita?

Este é um problema muito grande hoje, com coisas como o Firesheep sendo usado de forma bastante ampla.

    
por 30.03.2011 / 03:28
fonte
1

Só porque o Y2K acabou não significa que os programadores terminaram de escrever a data e erros de tempo. Havia famílias inteiras de insetos que atingiram perto e por volta do ano 2000. Os bugs de data e hora que continuam a surgir continuam me entretendo criatividade.

Apesar de ser antigo e se tornar datado, os seguintes fãs tiveram alguma popularidade em a corrida até o ano 2000 e ainda tem algumas informações atuais.

link

Enquanto o hardware legado meu eventualmente morre, os formatos de dados legados continuam vivos.

    
por 29.03.2011 / 20:04
fonte
-1

Contador de 32 bits em vários MIBs de hardware de rede. Eles podem envolver muito rápido e ainda em algum momento são usados para faturamento ...

    
por 30.03.2011 / 01:15
fonte
-4

Não é o mesmo, mas o número 10100401822940525 não existe em Javascript ou ActionScript 3.

Specifically, we found that the number 10100401822940525 appears to simply not exist in these programming environment. You can test this for yourself, simply trace or log the following statements: 10100401822940524 10100401822940525 10100401822940524+1 Number(“10100401822940525″) (10100401822940525).toString()

All of the above statements will output “10100401822940524″, when obviously all but the first one should return “10100401822940525″.

Theres no obvious significance to that value. The binary/hex value isn’t flipping any high level bit, and there are no results for it on google or Wolfram Alpha. Additional testing showed the same result with other numbers in this range.

Mistério solucionado aqui:

por 29.03.2011 / 09:04
fonte