Discussion :

[zan33]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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);
}

[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.

[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

[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 ?

[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...

[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) ?

[Médinoc]

De plus, ton code contient un appel à une fonction _filbuf(FILE*) qui n'est pas définie ici.

[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.

[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.

[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