Compilador Harbour com bug ao fazer comparações!

[NiltonGM]

Prezados,
O compilador Harbour está com bug estranho ao fazer comparações seja de variáveis ou Value de componentes, no principio achei q era um bug da class TMySQLQuery(), mas não é, ocorre o seguinte no exemplo simples abaixo para entender:

/* inicio ***********************

cAlterou := "" // Vazio

if "fjsdkfsdfd" != "" // Aqui está considerando iguais (estranho pra caramba), retorna .F. (troquei o != para <> mas não funcionou também)
cAlterou := 'ALTERADO"
end

? cAlterado // Retorna "" // Extranho

*Fim***/
Para contornar esse problema tive que fazer dessa forma:
/** Inicio ***

if !("fjsdkfsdfd" == "") // Aqui está considerando diferentes (óbvio), retorna .T.
cAlterou := 'ALTERADO"
end

? cAlterado // Retorna "ALTERADO" // Funciona!!

Uso HMG 3.3.1 compilando aplicativos em 32bits

[Jairo Maia]

Olá Nilton,

Confirmo! Compilado com Harbour 3.0 e Harbour 3.2.

Também um bug com Matriz que se mantém no Harbour e vem desde o Clipper é este:

Código: Selecionar todos

aTeste := {}
AaDd( aTeste, "1234" )
AaDd( aTeste, "abcd" )
AaDd( aTeste, "ABCD" )
? AScan( aTeste, "" )  // retorna 1

[Itamar M. Lins Jr.]

Ola!

! use HB_ASCAN( x, y,,, .T. ) to avoid relying on _SET_EXACT
% use ASCAN() instead of HB_ASCAN() if Harbour extension are not used (hbdoc)

Código: Selecionar todos

Function main
aTeste := {}
AaDd( aTeste, "1234" )
AaDd( aTeste, "abcd" )
AaDd( aTeste, "ABCD" )
? hb_AScan( aTeste, "",,,.t. )  // retorna 0

Saudações,
Itamar M. Lins Jr.

[Jairo Maia]

Olá Itamar,

Esta foi a solução encontrada desde o Clipper, mas continua extranho pois não acho que precisa ser comparação exata para saber que "fjsdkfsdfd" é diferente de "", e que na Matriz não há elemento vazio. Muito extranho.

Código: Selecionar todos

lExact := Set(_SET_EXACT, .t. )

cAlterou := ""
If "fjsdkfsdfd" != ""
 cAlterou := "ALTERADO"
end
? cAlterou  // retorna ALTERADO (correto)

aTeste := {}
AaDd( aTeste, "1234" )
AaDd( aTeste, "abcd" )
AaDd( aTeste, "ABCD" )
? AScan( aTeste, "" )  // retorna 0 (correto)

Set(_SET_EXACT, lExact )

[Itamar M. Lins Jr.]

Ola!
Eu perguntei ao Viktor se é um comportamento normal.
O Viktor respondeu.
No caso da ascan, usar hb_ascan(,,,,.t.) Já no != (not equal) leia abaixo:

Yes, unfortunately. It is also the reason why Harbour codebase never uses != (and =, <>, #) operators. They all depend on the SET EXACT setting. See the dozens of commits addressing that throughout the years.

A better behavior would be a compiler warning in -w3 mode.

This is one of those features inherited from ancestors, which would better be deprecated, along with other things like PUBLIC/PRIVATE vars, macros (in strings for sure), &&/* comments and some more.

In the meantime, use x == y and ! x == y

Saudações,
Itamar M. Lins Jr.

[NiltonGM]

Nunca tinha me ocorrido esse bug em clipper com string, em array não tinha passado por essa situação, só em Harbour é que me deparei com bug.
Procurarei usar sempre == ou !(==) e não vejo problemas deixar no inicio da aplicação setado Set(_SET_EXACT, .t. ) e durante toda aplicação.
Obrigado a todos.

[Jairo Maia]

Olá Pessoal,

não vejo problemas deixar no inicio da aplicação setado Set(_SET_EXACT, .t. )

Quanto aos operadores também não vejo problemas, é perfeitamente absorvível. Mas setar Set(_SET_EXACT, .t. ) como global, pode prejudicar outros tipos de pesquisa, como por exemplo a busca de um cliente pelo primeiro nome, e a tabela para no primeiro "Jairo" por exemplo. Se estiver setado comparação exata, somente será encontrado se procurar por "Jairo Maia", e com espaços no final que complete o tamanho do campo, algo como: PadR( "Jairo Maia", nLenCampo ). Mas depende muito da forma que se projeta o aplicativo. No meu caso isso não é possível.

EM TEMPO:
Hoje sabemos que o futuro do Harbour está nas mãos do Viktor, confesso que me preocupa muito ver alguns aspectos na declaração dele:

This is one of those features inherited from ancestors, which would better be deprecated, along with other things like PUBLIC/PRIVATE vars, macros (in strings for sure), &&/* comments and some more.

Difícil saber o que ele está pensando. É difícil também saber como programar sem esses recursos. Sei Lá.

[Nascimento]

amigo refiz o seu teste e aqui deu o bug inicialmente mais quando eu separei as "" que estavam juntas ai passou normal

Código: Selecionar todos

proc main()
cAlterou := " " // Vazio estavam juntas "" eu dei um espaço
if "fjsdkfsdfd"  <> " " // Aqui está considerando iguais (estranho pra caramba), retorna .F. (troquei o != para <> mas não funcionou também)
cAlterou := "ALTERADO"
end

? cAlterou // Retorna "" // Extranho

[Itamar M. Lins Jr.]

Ola!

EM TEMPO:
Hoje sabemos que o futuro do Harbour está nas mãos do Viktor, confesso que me preocupa muito ver alguns aspectos na declaração dele:

Permita-me discordar.
Sozinho ele não vai a lugar algum. Ele usa a versão central (3.2) todas as modificações do Przemyslaw Czerpak, Mindaugas Kavaliauskas, Phil Krylov entre outros
estão na versão dele.
Existe a versão principal que ele segue, todos devem seguir a versão principal, pelo menos deveria, mas a versão principal não pode seguir os caprichos de todos.

Saudações,
Itamar M. Lins Jr.

[Nascimento]

Na minha humilde opnião deveriamos dar Graças a Deus por essas pessoas ter criado o harbour e evoluido como vem ate hj
so em eu ver meu sisteminha mesmo modo console rodando em um Windows7,Linux sem esta tendo que fazer gambiarras pra funcionar o que antes era digamos impossivel em clipper ja me dou por satisfeto na verdade satisfeitissimo! e sabendo que o Viktor faz a junçao do harbour original com melhorias melhor ainda
so tenho que dar os parabens a estas pessoas

[JoséQuintas]

Apesar de tudo, não é bug.

O contrário de x = y é x != y
O contrário de x == y é .NOT. x == y

Desde o tempo do dBase, na comparação pode ser considerado o menor dos tamanhos das strings sendo comparadas.
"A" = "AB" pode ser considerado verdadeiro
"" = "QUALQUER COISA" idem
Obs. Não necessariamente nessa ordem.

Aí que entra o SET EXACT ON.

Agora, sobre eliminar macro, PUBLIC e PRIVATE, realmente é complicado.
Mesmo tendo alternativas, praticamente faz parte, principalmente na hora de converter fontes antigos.

[Itamar M. Lins Jr.]

Agora, sobre eliminar macro, PUBLIC e PRIVATE, realmente é complicado.
Mesmo tendo alternativas, praticamente faz parte, principalmente na hora de converter fontes antigos.

Quanto a isso também não vejo problema.
Fica digamos, da versão 1 até 3.99 usando macros,public,private e da versão 4 já sem essas coisas, se for uma visão global de interesse de todos a eliminação de PUBLIC, PRIVATE, MACROS, ETC.

Mas isso anda bem devagar dará tempo de ajustar nossos códigos, eu mesmo uso e abuso de variáveis private e macros, nem sei como resolveria o problema das macros.

Saudações,
Itamar M. Lins Jr.

[asimoes]

Até lá espero estar aposentado, hehehe.