Pour prouver qu'un executable X correspond bien au sources Y ont le recompile et on compare le nouvel EXE avec X... règle qui dans la pratique fonctionne bien.  
 
Seulement voilà nous avons un programme utilitaire de compression de fichiers qui lui semble n'en faire qu'à sa tête...  des compilations successives peuvent apparement générer des exécutables différents et là ça devient plus problèmatique quand il faut justifier l'origine de cet exec...  
 
Le compilateur en question est toujours notre fidèle BC++ v3.1  qui tourne sous DOS, le code lui est en C!
 
Y'a-t-il des méchanismes qui peuvent engendrer ce genre de phénomène, s'agit-il peut-être d'un bug du compilateur ou pourquoi pas d'un bug caché dans le source?  
 
Merci pour vos lumières

regarde si BC++ sait signer le code. si oui, alors les exe devraient avoir la même signature...
 
PS : et compile toujours depuis la même machine, parceque d'une machine à l'autre, en mode "par défaut", le compilo risque d'utiliser des optimisations différentes selon les capacités de l'architecture (genre si tu compile sur un AMD, il y a des chances pour qu'il ajoute les instructions 3DNow dans l'exe, alors que sur un Intel, il mette les SSE)
 
en tout cas, c'est la seule explication logique qui me vient à l'esprit

je sais que perso, on met dans le fichier un identifiant de build, avec la date, l'heure et la machine ayant servi à la compilation, pour tracer les binaires en production

il est possible de générer une signature de type hash-MD5 par exemple sur les exécutables, et de tenir un tableau à jour en indiquant "pour tel signature donnée, on a telle version de programme".

en fait, d'après la question, il faudrait plutôt signer le source, et inclure cette signature dans l'exe.
car d'après avander, le même source est capable de produire deux exe différents (:heink

euh, c'est pas le principe du checksum ca ?

 
C'est un peu la question en fait: un même source peut-il générer des exe's différent?
 
J'aurais tendance à dire que non alors que je suis confronté au contraire, donc soit y'a un truc qui m'échappe ( probable), soit il y a peut-être une explication plausible ( un compilo pour moi c'est une boite noire) mais que j'ignore...
 
C'est clair que la machine peut influencer mais ce n'est pas le cas ici.
 
 
 

 
j'ai déjà répondu oui ....

oui. Selon les options du compilateurs, les options de compilation, etc...

c clair que déjà, selon les options du compilo, il va pas faire du tout le même code.

Est-ce que vous croyez vraiment que je vais m'amuser à changer de machine, voir aller changer les options d'optimisation dans mon project-file alors que l'objectif est justement d'obtenir un executable identique?
 
NON et pourtant on observe des différences ( parfois qu'une dizaine de bytes certes), si c'est normal j'aimerais comprendre et alors il va falloir trouver une autre technique pour dire tel code source correspond à tel executable...
 
On est toujours parti du principe que l'executable était en quelque sorte un 'gros' hash du code fourni en entrée. On change un ligne et paf on a un nouvel hashcode, ce qu'on observe ici c'est que le hashcode change sans modif apparente du code source.    
 
Apparement vous semblez me dire que la compil ne peut pas être considéré comme un hash?  

oui.
 
le moyen le plus propre, c'est de faire une macro de compilation, qui vai faire un MD5 de tout le code, avant de l'injecter dans une constante du code, afin qu'il soit contenu dans l'EXE.
 
ou plus simplement utiliser la numérotation de version du compilo s'il le permet.

Si ton source fait des trucs du genre :

Alors forcément deux compils du même code vont donner deux binaires différents.

Certes, mais ce n'est pas le cas...

 
Oui, par exemple si le compilateur fait des optimisations en fonction de son temps d'exécution (il optimise durant 10 secondes max par exemple). Du coup, en fonction de la charge de la machine, le résultat peut varier de manière plus ou moins significative

Merci, j'ignorais... mais je doute que ce genre de technologie de pointe était déjà d'usage sous MS-DOS... :-).

Utilisation d'une hashtable dans le compilo pour référencer "kkchose" qui s'initialise +/- aléatoirement ptêtre...
 
On  trouve par exemple ça dans la doc de gcc :

Euh... si t'injectes le résultat du MD5 du code dans le code, le code change donc le MD5 change aussi donc faut réinjecter le nouveau MD5 dans le code mais le code change de nouveau donc le MD5 change donc...  

et vice et versa

Si il est possible de modifier à la main un executable juste apres la compilation, du genre en fin de ce fichier executable mettre un identifiant la date, si oui alors je vois pas le souci.

Pas besoin de modifier à la main, tu fais comme dans mon exemple.

suffit de faire un fichier dédié qui contient le code MD5
en fait, j'imagine un fichier include qui contient en constante le code MD5.
=> à la compilation, le code est donc recopié dans l'exe.
=> lors du calcul du MD5, on ne prends pas ce fichier.
 
ça me semble aisé à faire, avec un simple makefile

+1
 
mais faut que cette constante MD5 soit mise sous forme de string ce qui permettra ensuite de l'extraire plus facilement (avec des outils comme "string" sous unix ou autres)...

Un poil lourdingue le calcul du md5 de l'ensemble des fichiers source quand même