Ponteiros 64Bits

[passarito]

Boas a todos.

Algum tempo atrás desenvolvi uma app(zita) para pesquisar e apagar ficheiros antigos:

https://www.portugal-a-programar.pt/topic/50296-pesquisa-na-estrutura-de-directorios/page__st__60__hl__deloldf?do=findComment?comment=437744

Agora tive necessidade de correr aquilo em x64 e começaram os meus problemas:

1. Arranjar o IDE+Compilador para x64.

Só arranjei em russo ou Ucraniano ou coisa que o valha, mas consegui compilar.

2. O programa compilado executa mas estoira nos ponteiros. Alguém sabe se há alguma incompatibilidade dos ponteiros no x64?

Já agora, se alguém souber de um IDE+Compilador (mesmo em modo de texto), para windows x64 seria muito bom para e tentar resolver este problema.

Obrigado

[nunopicado]

O FPC tem para x64.

Já o testaste?

[passarito]

Sim, já fiz o download de 2 FPC's para win X64, mas não têm o IDE.

Experimentei também compilar aquilo com o Delphi 7 e com o Lazarus, mas estes não compilam programas de Pascal puro.

Descobri aqui num disco esquecido um IDE do FPC 2.4.4 win32

Vamos lá ver se isto depois de compilado funciona no win64....

[nunopicado]

Instalas o FPC normal (Win32), e depois metes-lhe o Win64 na mesma pasta.

Tens depois de alterar nas opções qual o compilador a usar.

[passarito]

Obrigado, vou tentar isso.

Amanhã digo-te qq

[passarito]

Aqui vai o resultado: Consegui meter o FPC no win64, compila, corre, mas quando passa pelos ponteiros (memória) os erros continuam ...

[nunopicado]

Não sei o que te diga...

[passarito]

olha, nem eu....

mas vou-me desenrascar de outra maneira qualquer e quando tiver tempo arranjo o programa de maneira a não usar ponteiros,com arrays grandes ou com 2 ficheiros txt ou outra solução qq.

Obrigado na mesma

fica bem

[nunopicado]

Passa isso para objectos, e usa uma classe para isso (estou a falar, mas não sei em quê que estás a usar os ponteiros).

[thoga31]

É a primeira vez que ouço falar de problemas deste género com ponteiros em Pascal entre x86 e x64. Não entendo qual possa ser o problema.

Não analisei o código por completo. @passarito, indicaste expressamente e de alguma forma o tamanho das variáveis nos endereços? Por exemplo, em C, se não usas a função sizeof vais ter problemas bastante sérios.

O que eu uso são arrays dinâmicos. Quando implementados com optimização em mente, eles tornam-se seguros, fáceis de manipular e fáceis de manter em código.

[passarito]

Não analisei o código por completo. @passarito, indicaste expressamente e de alguma forma o tamanho das variáveis nos endereços? Por exemplo, em C, se não usas a função sizeof vais ter problemas bastante sérios.

Pode ser disso, na realidade eu não uso o sizeof(), estou a usar o new()

O que eu uso são arrays dinâmicos. Quando implementados com optimização em mente, eles tornam-se seguros, fáceis de manipular e fáceis de manter em código.

Depois de do meu ultimo post lembrei-me que o FPC tem arrays dinâmicos e que seria uma possibilidade bastante viável.

[pwseo]

passarito,

Testei isto com o gdb e vi que o problema era uma segfault numa função fpc_shortstr_compare, invocada na tua regista_ficheiro. Isto ocorria apenas nalgumas iterações específicas, e então reparei que o problema reside nas linhas 101 e 116 (são iguais):

While (NovoReg^.AllPath>=Aux1^.AllPath) AND (Aux1<>NIL) do begin

A explicação é simples: em primeiro lugar, o programa vai comparar novoreg^.allpath com aux1^.allpath, e depois vai verificar se aux1 é ou não nil. Ora, quando aux1 é de facto nil, então a própria comparação entre os allpath de novoreg^ e aux1^ é a causa da segfault porque estará a ser feita uma access violation (i.e. não podes aceder ao campo allpath de aux1 se este último for nil).

Solução: primeiro verificar se é ou não nil e depois aí sim comparar os campos. O impressionante é isto funcionar em 32-bit (segundo dizes), pois trata-se de um problema independente da "bitness" do programa/processador; de facto, deveria falhar sempre.

Nota: testei a correcção no Ubuntu 14.04 64-bits com o fpc v2.6.2 e funcionou sem problemas.

Edited September 4, 2014 by pwseo

[passarito]

pwseo,

Obrigado pelo estudo aprofundado do problema.

Quanto ao funcionar em 32-bits, posso-te garantir que desde que fiz o programa até hoje, este, esteve e ainda está atrabalhar em 2 PC's Win XP 32 bits. Um de partilha de ficheiros e outro servidor de FTP.

Já apanhei com cada uma... esta é só mais um para o role!

[nunopicado]

Possivelmente nem tem a ver com o número de bits, mas com a forma de lidar com os AV's do compilador.

Possivelmente o BP7 dá a volta ao esquema sem se queixar, ou então testa as condições da direita para a esquerda...

No FPC 32 bits dá erro?

[pwseo]

Após ler um pouco mais, fiquei a saber que a ordem de avaliação dos operandos de and e or não está definida no Standard; fica ao critério da implementação.

Para colmatar essa falha, o Extended Pascal incluiu dois novos operadores (and_then e or_else) que só avaliam o 2º operando se o primeiro for equivalente a true.

Actualmente, só vi o GNU Pascal a implementar estes operadores. No caso do FreePascal, os operadores booleanos fazem curto-circuito e são sempre avaliados da esquerda para a direita, comportando-se por defeito como os and_then e or_else do Extended Pascal.

Nota: se o programa for compilado com {$B+}, então o curto-circuito não é feito e ambos os operandos são avaliados o que, neste programa, resultaria em access violations independentemente da ordem das verificações.