No gcc alguns undefined behaviors resultam em segmentation fault, como é o caso da divisão por zero. Já outros podem ou não emitir warnings conforme você especificar durante a compilação.
Os compiladores normalmente fazem um bom trabalho ao escolher o que fazer com um undefined behavior. Mas o ponto é: Uma coisa é você desconhecer como funciona a feature, outra é a linguagem especificar que ela não faz idéia do que pode acontecer. Isso sim é bizarro, na minha opinião. Abraços 2011/2/14 Tiago Peczenyj <[email protected]>: > E se o compilador jogasse um warning quando estamos usando algo que > claramente tem undefined behavior (como alguns casos tabelados) ? > Seria o melhor dos dois mundos: ou o programador sabe com certeza o que esta > fazendo ou o compilador/interpretador/etc avisa "hum... danadinho..." > > 2011/2/14 Blabos de Blebe <[email protected]> >> >> >> Enfim, o que quero dizer é que o Perl tem um imenso potencial de >> >> produzir >> >> código cheio de Pseudo-undefined Behavior; por que ninguém tem >> >> obrigação de >> >> saber todas as faces de todos os operadores; isso sem contar as >> >> L<perlvar>. >> >> Este email também tem potencial pra produzir undefined behavior. >> Deveríamos parar de escrever emails por causa disso? >> >> Opa, espere um momento. Como assim um programador não deve saber >> exatamente o que ele está usando? >> >> É claro que o programador *tem* sim que conhecer exatamente como >> funciona cada token que ele está usando, senão é melhor ir vender água >> de coco na praia. >> >> É por isso que certas empresas abrem certas falhas de segurança em >> certos servidores de produção. >> >> O problema é que Perl é uma linguagem muito abrangente e concordo com >> vc que é praticamente impossível memorizar todos os operadores. Mas se >> vc *usa*, vc é obrigado a saber. >> >> O ponto aliás nem é esse. Desconhecer, não implica em undefined >> behavior. Implica em não obter o resultado que era esperado, logo a >> falha está em não ser competente o suficiente para usar esta >> ferramenta da linguagem. >> >> Já em C por exemplo, existem construções que *produzem* undefined >> behavior, ou seja fica a cargo de quem implementou o compilador >> resolver. Se ele quiser formatar seu disco ao atingir um ponto desses, >> ele é livre pra isso. >> >> Por exemplo, o padrão C não define se variáveis automáticas (alocadas >> na pilha) são ou não inicializadas automaticamente. Daí, num >> compilador do Solaris (o Fernando pode confirmar), todas as variáveis >> automáticas são inicializadas automaticamente (zero para inteiros). Já >> no gcc não (mantém-se o valor que já estava na memória). Então, você >> escreve um código no Solaris, compila, testa, homologa e ok. Aí você >> leva esse código, que está dentro do padrão, para compilar no gcc e ao >> rodar na nova plataforma ele quebra. >> >> Isso sim é um problema. O mesmo código, estritamente dentro do padrão, >> apresentando comportamentos diferentes dependendo da situação. >> >> Oras, o programador experiente tem que conhecer bem a linguagem pra >> não cair nessas armadilhas. Se não conhece, não deveria codificar >> *profissionalmente*. >> >> É como se eu pegasse uma faca e saísse dizendo que sou cirurgião, só >> porque sei cortar carne. E aí, posso fazer uma neurocirugia em você? >> Eu tenho potencial pra ser um ótimo cirurgião :) >> >> As pessoas tem que ter mais responsabilidade. Hoje qualquer mané que >> mal consegue encadear uma idéia, aprende um if e um for, copia e cola >> Perl 3 do forum ultra hacker e sai falando que é Analista Programador. >> É foda viu! >> >> De qualquer forma eu acho ótimo esse debate com pontos de vistas >> diferentes. Ninguém é dono da verdade. >> >> Abraços >> >> 2011/2/14 Stanislaw Pusep <[email protected]>: >> > Aliás, o que explode o meu cérebro é a frase "These rules look >> > complicated, >> > but usually they will do what you want.", a respeito do "given/when", >> > também >> > em L<perlsyn> ;) >> > >> > ABS() >> > >> > >> > >> > 2011/2/14 Stanislaw Pusep <[email protected]> >> >> >> >> Ehehe, vou tentar contextualizar a minha lembrança... Tomo como exemplo >> >> a >> >> "tabela-verdade" do operador ~~ ("smart matching", L<perlsyn>): >> >> >> >> $a $b Type of Match Implied Matching Code >> >> ====== ===== ===================== ============= >> >> Any undef undefined !defined $a >> >> >> >> Any Object invokes ~~ overloading on $object, or dies >> >> >> >> Hash CodeRef sub truth for each key[1] !grep { >> >> !$b->($_) } >> >> keys %$a >> >> Array CodeRef sub truth for each elt[1] !grep { >> >> !$b->($_) } >> >> @$a >> >> Any CodeRef scalar sub truth $b->($a) >> >> >> >> Hash Hash hash keys identical (every key is found in >> >> both hashes) >> >> Array Hash hash slice existence grep { exists >> >> $b->{$_} } @$a >> >> Regex Hash hash key grep grep /$a/, keys >> >> %$b >> >> undef Hash always false (undef can't be a key) >> >> Any Hash hash entry existence exists $b->{$a} >> >> >> >> Hash Array hash slice existence grep { exists >> >> $a->{$_} } @$b >> >> Array Array arrays are comparable[2] >> >> Regex Array array grep grep /$a/, @$b >> >> undef Array array contains undef grep !defined, >> >> @$b >> >> Any Array match against an array element[3] >> >> grep $a ~~ $_, >> >> @$b >> >> >> >> Hash Regex hash key grep grep /$b/, keys >> >> %$a >> >> Array Regex array grep grep /$b/, @$a >> >> Any Regex pattern match $a =~ /$b/ >> >> >> >> Object Any invokes ~~ overloading on $object, or >> >> falls >> >> back: >> >> Any Num numeric equality $a == $b >> >> Num numish[4] numeric equality $a == $b >> >> undef Any undefined !defined($b) >> >> Any Any string equality $a eq $b >> >> >> >> 1 - empty hashes or arrays will match. >> >> 2 - that is, each element smart-matches the element of same >> >> index >> >> in the >> >> other array. [3] >> >> 3 - If a circular reference is found, we fall back to >> >> referential >> >> equality. >> >> 4 - either a real number, or a string that looks like a number >> >> >> >> Olha, não sei quanto aos outros participantes da lista, mas eu >> >> simplesmente não consigo me ater a todos esses detalhes >> >> :( >> >> Então nunca uso esse operador que me confunde (PARA MIM, é um >> >> "Undefined >> >> Behavior"), preferindo fazer "à moda antiga" (última coluna). Enfim, >> >> sou >> >> desses caras que enchem qqer operação de ()'s, tipo: ((($x / $y) - $z) >> >> > 0). >> >> Enfim, o que quero dizer é que o Perl tem um imenso potencial de >> >> produzir >> >> código cheio de Pseudo-undefined Behavior; por que ninguém tem >> >> obrigação de >> >> saber todas as faces de todos os operadores; isso sem contar as >> >> L<perlvar>. >> >> >> >> ABS() >> >> >> >> >> >> >> >> 2011/2/14 Blabos de Blebe <[email protected]> >> >>> >> >>> Oras, isso me lembra >> >>> >> >>> http://www.ioccc.org/1987/wall.c >> >>> >> >>> Uma coisa é você usar isso em um golf, outra é usar em código de >> >>> produção. >> >>> >> >>> Tem gente que empeteca o código com meia dúzia de regexp e se ahca 'O >> >>> Hackerzão'. >> >>> >> >>> A maior parte dos bugs (com os quais estou lidando agora, por >> >>> exemplo), teria sido evitada se fossem respeitados os padrões mínimos >> >>> de boas práticas. Coisa que qualquer estagiário *deveria* sair da >> >>> escolinha sabendo. >> >>> >> >>> Abraços >> >>> >> >>> 2011/2/14 Stanislaw Pusep <[email protected]>: >> >>> > Não sei pq, mas lembrei da seguinte sintaxe, compilável em Perl: >> >>> > >> >>> > -f>@+?*<.-&'_:$#/%! >> >>> > >> >>> > ABS() >> >>> > >> >>> > >> >>> > >> >>> > 2011/2/14 Blabos de Blebe <[email protected]> >> >>> >> >> >>> >> Bom dia, >> >>> >> >> >>> >> Sem querer entrar em flames, ou no mérito da discussão, que tomo >> >>> >> apenas como exemplo. >> >>> >> >> >>> >> A thread abaixo é uma discussão que está acontecendo na principal >> >>> >> lista de C++ brasileira, sobre undefined behavior. >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> http://groups.google.com/group/ccppbrasil/browse_thread/thread/9b9a7be45917095e# >> >>> >> >> >>> >> Notem como o Undefined behavior deste exemplo em particular pode >> >>> >> ser >> >>> >> resolvido com 'codificação elegante'. Ok, o assunto era outro e foi >> >>> >> só >> >>> >> um exemplo rápido, mas levantou a discussão que está acontecendo >> >>> >> até >> >>> >> agora. >> >>> >> >> >>> >> A maioria dos 'Undefined Behaviors' das linguagens de programação >> >>> >> que >> >>> >> conheço (não são muitos) são casos específicos, incomuns, bem >> >>> >> documentados, bem avisados, normalmente abertos por 'depender da >> >>> >> implementação' e invocados por código porco de programadores >> >>> >> meia-boca >> >>> >> (não que este caso de *exemplo* seja um). >> >>> >> >> >>> >> É claro, nenhuma linguagem é perfeita (exceto lisp), mas elas >> >>> >> possuem >> >>> >> especificações, mais abrangentes ou menos abrangentes. Por isso, >> >>> >> não >> >>> >> importa a linguagem, ou você se aprofunda e aprende, ou mais cedo >> >>> >> ou >> >>> >> mais tarte, vai acabar caindo em alguma dessas asrmadilhas. >> >>> >> >> >>> >> Na minha opinião, C tem mais armadilhas e/ou hacks que precisam de >> >>> >> um >> >>> >> pouco mais de conhecimento de arquitetura de computadores para >> >>> >> escapar >> >>> >> do que Perl, enquanto Perl tem outros tipos de armadilhas. >> >>> >> >> >>> >> Entenda armadilha aqui como "algo que eu imaginava de um jeito, mas >> >>> >> aconteceu de outro", independente da expectativa ser razoável ou >> >>> >> não. >> >>> >> >> >>> >> O negócio é que como Perl é mais fácil de lidar do que C, você >> >>> >> alcança >> >>> >> as armadilhas de Perl mais cedo do que conseguiria caminhar em C >> >>> >> para >> >>> >> alcançar as suas, logo, Perl parece mais imprevisível. >> >>> >> >> >>> >> Abraços >> >>> >> =begin disclaimer >> >>> >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> >>> >> SaoPaulo-pm mailing list: [email protected] >> >>> >> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >> >>> >> =end disclaimer >> >>> > >> >>> > >> >>> > =begin disclaimer >> >>> > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> >>> > SaoPaulo-pm mailing list: [email protected] >> >>> > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >> >>> > =end disclaimer >> >>> > >> >>> > >> >>> =begin disclaimer >> >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> >>> SaoPaulo-pm mailing list: [email protected] >> >>> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >> >>> =end disclaimer >> >> >> > >> > >> > =begin disclaimer >> > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> > SaoPaulo-pm mailing list: [email protected] >> > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >> > =end disclaimer >> > >> > >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: [email protected] >> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >> =end disclaimer > > > > -- > Tiago B. Peczenyj > Linux User #405772 > > http://pacman.blog.br > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: [email protected] > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer > > =begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
