 | |
#1
 
| ||||
| ||||
|
problem on openqm ? -
09-05-2005
, 12:55 AM
|
FIRST, the compilation. I HAVE right away noticed with horror that there was not any warning> of activated and not any d'optimisation I HAVE therefore rajouté the classics -O2 -Wall -W. I specify that usually, I rajoute -Werror (and -Wextra and some> other very felt). I do not put in production a soft that does not compile not in these conditions. The result, by sévérité order: - 49 variable unused: that does not eat any bread, that proves just that the code would deserve to be reread. Let us pass. - 3 'warning: "/*" within how' : that is not serious either. Same conclusion that above. - 1 'çattach_error label' not goal defined used' : idem: non code reread. - 15 'between signed unsigned and comparison' : the interest of this warning is discutable. Mistrust, anyway.. - 6 'array subscript typical has çchar'' : simple méconnaissance of the C. To The final one, that not génère not of bug, usually. - 17 'wears expressions of cast have deprecated lvalues i's' : idem. - 1 'typical return çint defaults to'' : idem - 20 'implicit declaration of xxx function' : therefore not any vérification of prototypes. Ca is not well, even if that is not usually engraves. - 2 'body in if-statement year empty' : ca, generally, that hides of the bugs.. - 1 'of ordered comparison to point zero with integer' : oh, this is not beautiful.. - 1 'of unsigned expression comparison < 0 is always false': That, this is a bug. - 7 'format xxx, typical different arg' : in the better one of the cases, That does not put any problem, in the worse one of the cases, that crashe. Enters the two, there is the case or the générée chaine is does not import what. This are bugs. - 145 'might used xxx uninitialized be ...' : in 90% of the cases, this are true bugs. In the 10% of the cases remaining, this are of the constructions or gcc is mistaken, often switch without default (problem easily résolu while using an enum as variable of> switch) or buckles that always are executées at least once (but that, gcc not cannot know it). - 1 'operation one çp' undefined may be' : subtle and serious there BE A bug:> * (p + +) = table [*p]; The compiler is free to evaluate the expressions in the order that it wants. One cannot therefore to not know when the pointeur will be incrémenté. According to what it decides, the result will be different. - 1 ' typical conflicting function for built-in ': which function will be used to the final one? Bug.. - 2 'reaches end non of control-function void' : that are themselves bugs:> the function sends back does not import what, according to what |
Quote:
|
the registers of the processeur. - 24 'to cast to point of integer from size different' : One puts of the addresses in int, as that? This are bugs. - 4 'variable might be çlongjmp by xxx clobbered' now çvfork'' : Ca, this are serious bugs. Ca means them to consider that the> variable contains |
with effects of setjmp/longjmp edges. There is
Quote:
|
Therefore little of luck that that walks correctly. Therefore, rcapitulons: without even to have launched the program one has 185 bugs, 72 case to verify and 53 warnings without consequences. Quality code piètre, therefore. I tried next to launch it with valgrind. I hve of the to modify 2ß3 things so that it démare without root being and there, surprised: it does not have the same behavior in valgrind and aunched in direct. It does not go far to enough do although this be (in the 2 case, it himself> finishes in error, but not with the same error. ..). It has not exploitable d'output valgrind, but there, already, there is a big problem.. Brief, I not will not persist me, this program is good to remake. |
message origine
bonjour,
j'ai recommendez openqm et voila le rapport de compilation que l'on me
transmet qu'en pensez vous ?
cordialement
Quote:
|
D'abord, la compilation. J'ai tout de suite remarqué avec horreur qu'il n'y avait aucune warning d'activée et pas d'optimisation. J'ai donc rajouté les classiques -O2 -Wall -W. Je précise que d'habitude, je rajoute -Werror (et -Wextra et quelques autres bien sentis). Je ne mets pas en production un soft qui ne compile pas dans ces conditions. Le résultat, par ordre de sévérité: - 49 unused variables: ça ne mange pas de pain, ça prouve juste que le code mériterait d'être relu. Passons. - 3 'warning: "/*" within comment': ça n'est pas grave non plus. Même conclusion que ci-dessus. - 1 'label `attach_error' defined but not used': idem: code non relu. - 15 'comparison between signed and unsigned': l'intérêt de cette warning est discutable. Méfiance, tout de même... - 6 'array subscript has type `char'': simple méconnaissance du C. Au final, ça ne génère pas de bug, en général. - 17 'use of cast expressions as lvalues is deprecated': idem. - 1 'return type defaults to `int'': idem - 20 'implicit declaration of function xxx': donc pas de vérification de prototypes. Ca n'est pas bien, même si ça n'est en général pas grave. - 2 'empty body in an if-statement': ca, généralement, ça cache des bugs... - 1 'ordered comparison of pointer with integer zero': oh, c'est pas beau... - 1 'comparison of unsigned expression < 0 is always false': ça, c'est un bug. - 7 'xxx format, different type arg': dans le meilleur des cas, ça ne pose pas de problème, dans le pire des cas, ça crashe. Entre les deux, il y a le cas ou la chaine générée est n'importe quoi. Ce sont des bugs. - 145 'xxx might be used uninitialized ...': dans 90% des cas, ce sont des vrais bugs. Dans les 10% des cas restant, ce sont des constructions ou gcc se trompe, souvent des switch sans default (problème facilement résolu en utilisant une enum comme variable de switch) ou des boucles qui sont toujours executées au moins une fois (mais ça, gcc ne peut pas le savoir). - 1 'operation on `p' may be undefined': voilà un bug subtil et grave: *(p++) = table[*p]; Le compilateur est libre d'évaluer les expressions dans l'ordre qu'il veut. On ne peut donc pas savoir quand le pointeur sera incrémenté. Selon ce qu'il décide, le résultat sera différent. - 1 ' conflicting types for built-in function ': quelle fonction sera utilisée au final ? Bug... - 2 'control reaches end of non-void function': ça se sont des bugs: la fonction renvoie n'importe quoi, en fonction de ce que contiennent les registres du processeur. - 24 'cast to pointer from integer of different size': On met des addresses dans des int, comme ça ? Ce sont des bugs. - 4 'variable xxx might be clobbered by `longjmp' or `vfork'': Ca, ce sont des bugs graves. Ca veut dire qu'on peut considérer que la variable contient du garbage. Très mauvais présage: le code a été écrit sans se soucier des effets de bords de setjmp/longjmp. Il y a donc peu de chance que ça marche correctement. Donc, récapitulons: sans même avoir lancé le programme on a 185 bugs, 72 cas à vérifier et 53 warnings sans conséquences. Code de piètre qualité, donc. J'ai essayé ensuite de le lancer avec valgrind. J'ai du modifier 2~3 trucs pour qu'il démare sans être root et là, surprise: il n'a pas le même comportement dans valgrind et lancé en direct. Il ne va pas assez loin pour faire quoi que ce soit (dans les 2 cas, il se termine en erreur, mais pas avec la même erreur...). Il n'y a pas d'output de valgrind exploitable, mais là, déjà, il y a un gros problème... Bref, je ne vais pas m'acharner, ce programme est bon à refaire. |
#2
| |||
| |||
|
|
hello, I have give openqm and this compilation report that one transmits me that some think you? ...snip... |
The source that leaves here compiles cleanly with -Werror to force all
warnings to be errors. The open source is totally unsupported as we
have no control over what users do to it. If you can identify problems
in the commercial product, we will investigate further.
Martin Phillips
Ladybridge Systems Ltd
#3
| |||
| |||
|
|
helios wrote: hello, I have give openqm and this compilation report that one transmits me that some think you? ...snip... The source that leaves here compiles cleanly with -Werror to force all warnings to be errors. The open source is totally unsupported as we have no control over what users do to it. If you can identify problems in the commercial product, we will investigate further. Martin Phillips Ladybridge Systems Ltd |
the following messages concerns the OPENQM version GPL and not the
commercial version QM
the QM stability is not in causes and has this day no defaut does not have
been raises the OPENQM bug report after a resulte analyzes and deepened
discution with his author of a compilation of an altere source therefore
all the QM and OPENQM users are able are reassures there is no probleme
PRECISIONS afin de clarifier la situation
le messages suivant concerne la version GPL de OPENQM et non la version
commerciale QM
la stabilite de QM n'est pas en cause et a ce jour aucun defaut n'a ete
releve
le rapport de bug OPENQM resulte apres analyse et discution approfondie
avec son auteur d'une compilation d'un source altere
donc tous les utilisateurs de QM et OPENQM peuvent etre rassure il y a
aucun probleme
Quote:
#4
| |||
| |||
|
|
been raises the OPENQM bug report after a resulte analyzes and deepened discution with his author of a compilation of an altere source therefore all the QM and OPENQM users are able are reassures there is no probleme |
your web site; the first test with valgrind was made on the PPC code and on
your demand has been done with the linux code, again from your web site. As
an official openQM dealer, if the code that you provide is corrupted, I
don't know if one can trust you.
--
Stephan Peccini
PhotoNature : <URL:http://www.photonature.fr>
#5
| |||
| |||
|
|
The open source is totally unsupported as we have no control over what users do to it. If you can identify problems in the commercial product, we will investigate further. |
What's the difference between the open source and the commercial
product? Is it only support, or are there some functionalities only
available in the commercial version?
#6
| |||
| |||
|
|
Le Mardi 6 Septembre 2005 18:20, helios a écrit : been raises the OPENQM bug report after a resulte analyzes and deepened discution with his author of a compilation of an altere source therefore all the QM and OPENQM users are able are reassures there is no probleme To be completely honest, you should have said that this code was taken on your web site; the first test with valgrind was made on the PPC code and on your demand has been done with the linux code, again from your web site. As an official openQM dealer, if the code that you provide is corrupted, I don't know if one can trust you. -- this is not the code that I furnished that is corrompu this is the |
necessary explanations for effectuates the compilation correctly I am
ready has to do with him if it wishes it a test of compilations that will
show its error of procedures
the code furnishes such that it is allows to obtain an openqm version
without bugs the procedure uses by the testeur does not effectuate a
compilation completes openqm and therefore to create errors
I repeat therefore GPL OPENQM license and QM are totally exemptent of the
bugs raised by a bad usage of sources
many persons having read THE documents and applies ONE compiled without
problem and uses without openqm problem
#7
| |||
| |||
|
|
this is not the code that I furnished that is corrompu this is the testeur at has corrompu the d'openqm code and did not read the necessary explanations for effectuates the compilation correctly I am ready has to do with him if it wishes it a test of compilations that will show its error of procedures |
(and you have said that you do not know anything at all with gcc), knows
very well his job and he only tested your openQM version with valgrind. He
never touched the code (*.c and *.h) and his test can be made again. The
only modification he made was to add these options to the Makefile : -Wall
-W.
I stop here my discussion with you; you have proven on the french group that
you are a liar and invent quite everything and I don't want to disturb this
group.
--
Stephan Peccini
PhotoNature : <URL:http://www.photonature.fr>
#8
| |||
| |||
|
|
Le Mardi 6 Septembre 2005 20:47, helios a écrit : this is not the code that I furnished that is corrompu this is the testeur at has corrompu the d'openqm code and did not read the necessary explanations for effectuates the compilation correctly I am ready has to do with him if it wishes it a test of compilations that will show its error of procedures You simply are a liar. The person who made the test is a very competent one (and you have said that you do not know anything at all with gcc), knows very well his job and he only tested your openQM version with valgrind. He never touched the code (*.c and *.h) and his test can be made again. The only modification he made was to add these options to the Makefile : -Wall -W. I stop here my discussion with you; you have proven on the french group that you are a liar and invent quite everything and I don't want to disturb this group. -- |
it is her choice
but the more important it is that QM and OPENQM are containt not bug
QM and OPENQM are 100% good
#9
| |||
| |||
|
|
this is not the code that I furnished that is corrompu this is the testeur at has corrompu the d'openqm code and did not read the necessary explanations for effectuates the compilation correctly I am ready has to do with him if it wishes it a test of compilations that will show its error of procedures the code furnishes such that it is allows to obtain an openqm version without bugs the procedure uses by the testeur does not effectuate a compilation completes openqm and therefore to create errors I repeat therefore GPL OPENQM license and QM are totally exemptent of the bugs raised by a bad usage of sources many persons having read THE documents and applies ONE compiled without problem and uses without openqm problem |
#10
| |||
| |||
|
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.