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

Blabos de Blebe blabos at gmail.com
Mon Feb 14 09:40:35 PST 2011


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
>
>


More information about the SaoPaulo-pm mailing list