Então, até onde eu saiba, depende *de onde* vem a memória alocada :P O "normal" é que venha do stack; existe patch p/Linux p/limpar o stack, visando maior segurança a custo de performance. Mas em outras arquiteturas podem existir outras formas de alocar memória para as variáveis locais. Não conheço a fundo; mas garanto que mesmo em x86, há pelo menos 2 formas de passar parâmetros para uma subrotina: via stack ou via registros. Talvez algum dos flags de otimização do GCC faça com que, dependendo do caso, variáveis locais fiquem em registros, aí o *efeito colateral* seria zerá-las automaticamente.
ABS() 2011/2/14 Tiago Peczenyj <[email protected]> > 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. > > mas "zerar" um array é responsabilidade do sistema operacional ou não tem > nada haver? > > > 2011/2/14 Stanislaw Pusep <[email protected]> > >> 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! >> >> >> ABS() >> >> >> >> 2011/2/14 Blabos de Blebe <[email protected]> >> >>> 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 >>> >> >> >> =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
