[SP-pm] [OFF-TOPIC] Masturbações Mentais sobre Undefined Behavior
Tiago Peczenyj
tiago.peczenyj at gmail.com
Mon Feb 14 09:28:28 PST 2011
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110214/63744dc2/attachment-0001.html>
More information about the SaoPaulo-pm
mailing list