Newsgroup: it.comp.lang.vo-clipper
Titolo: Bug incredibile ....

Vi segnalo un probabile bug che ho riscontrato con VO 2.5b : (magari
qualcuno di voi lo ha gia' riscontrato)
in un programma gestionale a volte mi ritornava inspiegabilmente un errore
di questo tipo :
( lo riporto al completo x maggiore chiarezza)
Application: C:\SGA\SGA.EXE
Error message:
--------------
Error Code:  50 [ ACCESS VIOLATION ]
Subsystem: VO-CODE
Error Subcode: 5333
Argument Number: 2
Description: Application Code Error causing Access Violation
CallStack:
WND_PROVVIGIONI:PB_STAMPA (Line: 214)
APP:START (Line: 89)
Error Object created:
--------------------
SubSystem       :VO-CODE
SubCode         :      5333
GenCode         :Access Violation
ExceptionCode   :C0000005
ExceptionFlags  :00000000
ExceptionAddress:1001E9F7
ParamNumber     :         2
ExceptionInfo   :00000000
Severity        :         2
CanDefault      :.F.
CanRetry        :.F.
CanSubstitute   :.F.
Operation       :
Description     :Application Code Error causing Access Violation
FileName        :
Tries           :         0
FileHandle      :         0
SubCodeText     :
Arg             :
ArgTypeReq      :NIL
MaxSize         :         0
SubstituteType  :NIL
CallFuncSym     :
--------------------
il classico access violation !
Pensavo fossero errori causati da Window fintanto che non mi ha dato piu'
frequentemente l'errore su un banale calcolo di provvigioni.
L'errore me lo dava casualmente e diciamo una volta su 4. Il codice era
molto semplice :
        IF mImponibile*mProvFissa <> 0            // le variabili sono tutte
di tipo FLOAT con SetFloatDelta impostato al decimo decimale
             mImpoProv := PassImpo/100
        ENDIF
e me lo dava sempre sulla prima riga dell' IF ! Ne ho provate di tutti i
colori , variabili di classe invece che local , ecc non sapevo piu' come
correggere e sopratutto il motivo di tale (anzi tali perche' usato in piu'
parti del prg tale sistema) errore.
Alla fine in un momento di sconforto ho scritto :
        PassImpo := mImponibile*mProvFissa
        IF PassImpo <> 0
             mImpoProv := PassImpo/100
        ENDIF
ED NON MI HA PIU' DATO ERRORI !!!!   Perche' ???
Ciao a tutti ... Alessandro
(se succede anche a voi il problema di access violation guardate il codice
...)
aless...@computerscenter.com

ED NON MI HA PIU' DATO ERRORI !!!!   Perche' ???
Tempo fa (l'avevo notato anche in Clipper) infatti avevamo notato che
eseguendo dei calcoli, dove il risultato veniva assegnato ad una
variabile e successivamente confrontato, il programma era pių stabile
rispetto ad un confronto calcolato "al volo".
Inoltre, con VO, ormai cerco di evitare le variabili FLOAT, perchč
questo tipo di variabile incrementa l'uso di memoria dinamica
vertiginosamente.
Io al posto delle FLOAT utilizzo le REAL8.
Saluti
===============================================
Antonello Negrone - Biella - Italy
anto...@anc-software.it
www.anc-software.it

 Io al posto delle FLOAT utilizzo le REAL8.
Siamo in due. Comunque mi risulta che i DBF ( o almeno le funzioni che
leggono i dbf) utilizzano i float.
Ciao,
    Fabrizio Malaguti


 
www.anc-software.it
Secondo me non si tratta di un problema di stabilita' o meno ma di un vero e
proprio BUG.
Questo indipendentemente dal fatto che uso FLOAT al post di REAL8 (le quali
mi causavano
alcuni problemi nel loro uso che ora non ricordo bene).
Riguardo a Clipper non ho mai riscontrato problemi di questo tipo.
Cosa ne dicono i GURU dell'infirmatica e di VO ?
Ciao Alessandro.

calcolo ).
A me risulta che tutti i coprocessori Intel a partire dall'8087
abbiano registri interni a 80 bit.  Che poi sia piu' comodo
memorizzare i risultati in formato IEEE a 64 bit e' un altro paio di
maniche, di fatto i registri sono ad 80 bit; qualsiasi valore venga
caricato nei registri della FPU, sia esso in formato FP, BCD o Integer
subira' obbligatoriamente una conversione in formato FP ad 80 bit.
ciao, acc.   
a...@libero.it

 Riguardo a Clipper non ho mai riscontrato problemi di questo tipo.
Confermo. Neanch'io.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg

 ha scritto nel
messaggio news:xhSB8.12617$zW3.3...@news1.tin.it...


 ha scritto nel
messaggio news:L_UB8.13400$zW3.3...@news1.tin.it...


 Cosa ne dicono i GURU dell'infirmatica e di VO ?
dell'infirmatica? ;-)))))
Con Clipper il problema riscontrato era che i risultati ottenuti da
calcoli eseguiti "al volo" non erano sempre attendibili.
L'avevamo riscontrato con una applicazione non commerciale, quindi non
un gestionale tradizionale, che legge dei valori direttamente da una
scheda hardware utilizzando le funzioni di accesso all'hardware
contenute nelle CA-Tools.

 contenute nelle CA-Tools.
Ho programmato anch'io una schda di I/O scrivendo e leggendo la PIO ma
non credo c'entra molto con il problema in questione ... mai avuto poi
problemi
con Clipper ... del genere .
Ciao Ale.

Credo che questo bug  ( se di bug si tratta ) debba essere segnalato alla CA
non credete ?
(Sempre che le interessi ancora).
Ciao e grazie a tutti quanti.
Alessandro.

 Cosa ne dicono i GURU dell'infirmatica e di VO ?
non mi considero ne guru di informatica ne di VO, ma sei in grado di 
riprodurre l´errore in, diciamo 40 righe di codice, e di farmelo avere? Solo 
se l´errore è riproducibile si riesce a metterlo a posto. 
Fino adesso, ogni volta che avevo un problema riproducibile in un pezzo di 
codice corto, il bug è stato riparato. Così potremmo averlo messo a posto per 
la 2.6...
Saluti
Wolfgang
Merano

 ciao, acc.   
a...@libero.it

 Ciao, spero di esserti stato di aiuto.. ...
Marco, poichè lo stesso Brian si dice disposto a verificare i bugs di VO,
nella fase di rilascio della versione 2.6, credo che questa sia una buona
occasione: se riesci a fare un piccolo aef con un ciclo che ingarbuglia VO e
che non sia troppo lungo, lo puoi postare a 
sa...@grafxsoft.com
. Se hai
bisogno di una mano per spiegare il problema in inglese (il mio inglese!)
sono quà.
Ciao, Antonio

per compatibilità col CLIPPER? o che altro?
La FPU supporta nativamente i formati a 64 e 80 bit, nel caso dei 24
bit invece e' necessario effettuare una conversione che spesso e'
doppia, cioe' il dato viene convertito a 80 bit e dopo l'operazione
aritmetica viene riconvertito a 24 bit.
Questo problema non riguarda solo VO, ma la quasi totalita' dei
linguaggi, visto che quasi tutti si appoggiano su quel formato.
Il formato a 24 bit era piuttosto diffuso in passato, per motivi
simili al discorso su Clipper e cioe' la maggiore efficienza su
macchine prive di coprocessore.
Attualmente, vista la diffusione dei coprocessori, e' molto piu'
conveniente usare i 64 o gli 80 bit, o al limite usare la libreria di
emulazione.
Una curiosita': il formato a 80 bit era gia' gestito parecchio tempo
fa, in C si dichiara come "long double", pero' la "altmath" non lo
gestiva, o meglio al suo posto utilizzava il classico double a 64 bit.
ciao, acc.   
a...@libero.it

 fa, in C si dichiara come "long double",
Per la precisione, il long double è presente come standard solo in C++.
In C veniva fornito come estensione da qualche compilatore.


 la 2.6...
Ok provero' a riprodurlo in poche righe ... e poi te lo inviero'.
Ciao Alessandro.

In C veniva fornito come estensione da qualche compilatore.
Esatto, pero' il "qualche" mi sembra un po' riduttivo, diversi
compilatori C (non cpp) lo supportavano.
ciao, acc.   
a...@libero.it

 compilatori C (non cpp) lo supportavano.
Il "qualche" assume perfettamente senso se pensi che linguaggi come il C
e il C++ esistono su una miriade di piattaforme e il PC/Windows č solo
una di queste.


ok.
Grazie delle spiegazioni.
Ciao,
    Fabrizio Malaguti
"acc" <a...@libero.ita> ha scritto nel messaggio
news:43iodukidpchh8b9p...@4ax.com...
