[SP-pm] [OFF-TOPIC] Masturbações Mentais sobre Undefined Behavior

Tiago Peczenyj tiago.peczenyj at gmail.com
Mon Feb 14 10:10:05 PST 2011


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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at gmail.com>:
>> >> >>> > Não sei pq, mas lembrei da seguinte sintaxe, compilável em Perl:
>> >> >>> >
>> >> >>> > -f>@+?*<.-&'_:$#/%!
>> >> >>> >
>> >> >>> > ABS()
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > 2011/2/14 Blabos de Blebe <blabos at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>


-- 
Tiago B. Peczenyj
Linux User #405772

http://pacman.blog.br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110214/8e099afa/attachment-0001.html>


More information about the SaoPaulo-pm mailing list