[SP-pm] [OFF-TOPIC] Masturbações Mentais sobre Undefined Behavior
Stanislaw Pusep
creaktive at gmail.com
Mon Feb 14 10:27:28 PST 2011
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 <tiago.peczenyj em gmail.com>
> 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 <creaktive em gmail.com>
>
>> 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 <blabos em gmail.com>
>>
>>> 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 <tiago.peczenyj em gmail.com>:
>>> > 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 <blabos em gmail.com>
>>> >>
>>> >> >> 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 <creaktive em gmail.com>:
>>> >> > 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 <creaktive em gmail.com>
>>> >> >>
>>> >> >> 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 <blabos em gmail.com>
>>> >> >>>
>>> >> >>> 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 <creaktive em gmail.com>:
>>> >> >>> > Não sei pq, mas lembrei da seguinte sintaxe, compilável em Perl:
>>> >> >>> >
>>> >> >>> > -f>@+?*<.-&'_:$#/%!
>>> >> >>> >
>>> >> >>> > ABS()
>>> >> >>> >
>>> >> >>> >
>>> >> >>> >
>>> >> >>> > 2011/2/14 Blabos de Blebe <blabos em gmail.com>
>>> >> >>> >>
>>> >> >>> >> 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: SaoPaulo-pm em pm.org
>>> >> >>> >> 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: SaoPaulo-pm em pm.org
>>> >> >>> > 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: SaoPaulo-pm em pm.org
>>> >> >>> 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: SaoPaulo-pm em pm.org
>>> >> > 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: SaoPaulo-pm em pm.org
>>> >> 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: SaoPaulo-pm em pm.org
>>> > 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: SaoPaulo-pm em pm.org
>>> 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: SaoPaulo-pm em pm.org
>> 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: SaoPaulo-pm em pm.org
> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110214/e365d417/attachment-0001.html>
More information about the SaoPaulo-pm
mailing list