Réécriture sous 64 bits de fonction bas niveau utilisant une struct FILE

Version imprimable

Hello,

Une fonction a été écrite en C sous 32 bits en utilisant non pas les fonctions standards genre fgets() mais les pointeurs bas niveau sur une structure de type _FILE.
Or il semble que ce fonctionnement ne soit plus disponible sur un environnement 64 bits. Comment réécrire la fonction suivante svp ?

Merci.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
int machin(char *Buf, int Lg, FILE *Fic) {
      char *PtBuf;
      char Car;
      char *FinBuf;
 
      if (feof(Fic)) return(0);
      PtBuf = Buf;
      FinBuf = PtBuf + Lg - 1;
      do {
            if(Fic->_cnt == 0) {
                  _filbuf(Fic);
                  if(feof(Fic)) return(PtBuf - Buf);
                  if(Fic->_ptr != Fic->_base) {
                        Fic->_cnt += Fic->_ptr - Fic->_base;
                        Fic->_ptr = Fic->_base;
                  }
            }
            PtBuf[0] = Car = Fic->_ptr[0];
            Fic->_ptr ++;
            Fic->_cnt --;
            PtBuf ++;
      }
      while ((Car != '\n') && (PtBuf < FinBuf) && !feof(Fic));
      PtBuf[0] = 0;
      return(PtBuf - Buf);
}

29/03/2017, 12h58
ternel

Soit c'est du code interne de la bibliothèque standard, et dans ce cas, c'est déjà du travail de niveau gourou (implémenteur du langage)
Soit c'est du code "normal", c'est à dire venant de n'importe où d'autre, et dans ce cas, la struct FILE n'a pas de définition officielle, donc, tu ne devrais pas t'en servir.

Ma question est donc: pourquoi te retrouves-tu avec ce problème?

Je note qu'il y a quelque chose de bizarre: l'usage de feof alors que le reste de la fonction n'utilise aucune fonction sur le fichier.
feof se contente de regarder si le flag eof est défini dans le fic.
29/03/2017, 14h04
zan33

Réponse: C'est dans une application écrite par je-ne-sais-qui en Pro*C et C pendant les années 90, et les serveurs expirent.
Problème, on ne trouve plus que des serveurs 64 bits, et cinq programmes principaux de l'application à migrer invoquent des fonctions et des pointeurs de bas niveau qui ne fonctionnent plus en 64 bits.
Voir : https://technet.microsoft.com/sr-lat...%28v=vs.100%29
29/03/2017, 14h23
Matt_Houston

Des pointeurs « qui ne fonctionnent qu'en 32 bits », ça ne veut pas dire grand chose. Comment as-tu constaté le dysfonctionnement ? Que doit faire cette fonction ? Qu'est-ce qui empêche de la remplacer par un appel à fread ?
29/03/2017, 14h48
zan33

Le dysfonctionnement n'a pas été encore constaté, car le portage n'a pas encore eu lieu. Les renseignements préalables que je prends sur le net et ailleurs m'amènent à dire que l'on a de bonnes raisons de penser que l'écriture sous 64-bits de programmes utilisant la structure _FILE et les invocations de _ptr _base ou _cnt, ainsi que la manipulation de fichiers de plus de 2 Go vont amener des plantages et/ou des erreurs de compil.
Me trompé-je ?
Par ailleurs, je découvre ces programmes et n'ai pas l'information détaillée sur ce que font les fonctions en fait...
29/03/2017, 16h57
Matt_Houston

Tu nous demandes comment réécrire une fonction dont tu ne connais pas le rôle.. ça risque d'être compliqué.

FILE est une structure opaque de la bibliothèque standard. Comme l'a dit ternel tu n'es pas sensé la manipuler directement, à moins d'utiliser ta propre libc.

Il faut nous en dire plus sur ce programme. Quel est le contexte ? S'exécute-t-il en espace utilisateur (y'a-t-il un système d'exploitation derrière) ?
30/03/2017, 14h29
Médinoc

De plus, ton code contient un appel à une fonction _filbuf(FILE*) qui n'est pas définie ici.
30/03/2017, 14h37
zan33

On dirait que c'est en relation avec cet article : http://www.linuxjournal.com/article/2811
Je poursuis mes investigations.
On est dans une appli industrielle, mais pas système.
30/03/2017, 15h38
ternel

L'article dit "il y a le standard, mais comme ce n'est pas parfait, passent outre". Tu en paies le prix.

Ne pas respecter le standard, c'est prendre un risque à chaque changement: au changement de système, c'est sûr, mais aussi à chaque mise à jour de n'importe quel composant non respecté. Et pire, de chaque composant logiciel se servant du composant violé.

Imagine que tu change le fonctionnement "pour toi" d'un des membres de FILE*, il peut y avoir une bibliothèque, ailleurs, qui dépendant du fonctionnement initial.
Paf, ca fait des bugs complètement intraçables.

Quitte à migrer, reviens vers les fonctionnalités du standard, ou utilise une bibliothèque réputée qui fait le travail.

En résumé: ne tolère jamais l'utilisation de comportemenst indéfinis.
07/04/2017, 13h50
zan33

Oui, il semble que ce soit une réécriture de la fonction fgets() un peu gourou, on va revenir au standard.

Sinon vous connaissez un lien vers un sujet qui traite de la question suivante svp : en ayant un exécutable, comment savoir les différents .o qui ont servi à la constitution de celui-ci après éditions de liens ?

ldd est assez peu causant.

Merci
07/04/2017, 14h44
ternel

En général, on ne peut pas.
En pratique, on devrait éventuellement pouvoir retrouver les frontières entre les .o dans le code.
10/04/2017, 14h52
sambia39

Bonjour,

Citation:

Envoyé par zan33

Réponse: C'est dans une application écrite par je-ne-sais-qui en Pro*C et C pendant les années 90, et les serveurs expirent.
Problème, on ne trouve plus que des serveurs 64 bits, et cinq programmes principaux de l'application à migrer invoquent des fonctions et des pointeurs de bas niveau qui ne fonctionnent plus en 64 bits.
Voir : https://technet.microsoft.com/sr-lat...%28v=vs.100%29

Qu’est ce qui vous empêche de re-compiler les sources à votre disposition sur une architecture 64 bits et de voir ce que cela donne (on supposant que vous avez tous les fichiers sources permettant la compilation) A moins que le ne code source ne contient que des routines système et autres instructions en assembleur pour une architecture donnée qui le rend non portable dans ce cas oui une adaptation du code s’avèrent nécessaire.

D’un autre côté je ne vois pas trop ce que vous voulez dire par pointeur bas niveaux sachant qu’un pointeur est qu’une variable comme tant d’autres qui à la particularité de contenir que des adresses exemple l’adresse des "file descriptor" d’entrée sortie bas niveaux, mais cela ne veut pas dire que ce pointeur en question est un pointeur bas niveau, mais plutôt un pointeur qui contient l’adresse d’un élément bas niveaux (fd).

Citation:

Envoyé par zan33

On dirait que c'est en relation avec cet article : http://www.linuxjournal.com/article/2811
Je poursuis mes investigations.
On est dans une appli industrielle, mais pas système.

Je ne comprends pas. Admettant, si on est dans une application industrielle et non système c'est-à-dire une application faite pour des microprocesseurs, microcontrôleur des systèmes temps réel ou système de contrôle de processus. Plus précisément des applications ou logiciel qui sont des interfaces entre l'informatique et des appareils industriels je ne vois pas comment il ne peut y avoir de la programmation système. Ou j'ai pas saisie le sens de la phrase....

Citation:

Envoyé par zan33

Oui, il semble que ce soit une réécriture de la fonction fgets() un peu gourou, on va revenir au standard.

Sinon vous connaissez un lien vers un sujet qui traite de la question suivante svp : en ayant un exécutable, comment savoir les différents .o qui ont servi à la constitution de celui-ci après éditions de liens ?

ldd est assez peu causant.

Merci

On ne peut pas connaître avec exactitude les instructions sources qui ont permis à l’élaboration du programme exécutable, mais vous avez tout de même la possibilité de récupéré le modèle de conception de l’exécutable en procédant à la rétro-ingénierie du programme exécutable à condition que cela soit justifié dans votre cas c’est probable, car l’exécutable en question n’est peut-être pas portable sur d'autre architecture (parce que la plateforme matérielle a changé ou évolué); mais cela implique également d'avoir des connaissances nécessaires pour comprendre et re-crée le modèle de conceptions (il existe tout de même des outils qui facilitent le travail "en partie"). Toutefois je tiens à préciser qu’en Europe la rétro-ingénierie est tolérée; mais interdit quand celui-ci est utilisé pour une reproduction commerciale voire une publication de diverses informations obtenu par la rétro-ingénierie. (En France il faut voir du côté de l'article L122-6-1 du code de la propriété intellectuelle).
Tout de même, le plus simple serait de contacter l’éditeur du programme afin d’avoir les sources.

à bientôt