[SP-pm] [OFF-TOPIC] Masturbações Mentais sobre Undefined Behavior
Stanislaw Pusep
creaktive at gmail.com
Mon Feb 14 10:04:59 PST 2011
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
>
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110214/024277c3/attachment-0001.html>
More information about the SaoPaulo-pm
mailing list