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