Quelles sont les API affectées par {$IOCHECKS OFF} ?

Question

Nous avons un ancien code Delphi (qui pourrait même provenir d'un code Turbo Pascal) qui utilise {$I-} , alias {$IOCHECKS OFF} ce qui fait que le code utilise IORésultat au lieu d'exceptions pour les erreurs d'E/S de disque.

Je veux me débarrasser de la {$I-} et faire évoluer ce code vers les années 1990, mais pour cela, j'aimerais savoir ce qui est concerné par {$IOCHECKS OFF} . Cela affecte-t-il uniquement les vieilles fonctions d'E/S intégrées comme AssignFile / Reset / Rewrite / Append / CloseFile ? Ou est-ce que cela affecte également des fonctions plus modernes comme TFileStream ? Plus important encore, quelles sont les autres fonctions qui pourraient être affectées et auxquelles je ne pense pas ? ( Les bases de Delphi suggère que cela affecte également MkDir et RmDir. Si cela affecte ceux-là, il doit y en avoir d'autres).

La rubrique d'aide de Delphi 2007 "Contrôle des entrées-sorties (Delphi)" ( ms-help://borland.bds5/devcommon/compdirsinput_outputchecking_xml.html ) dit que cela affecte les "procédures d'E/S", et que "les procédures d'E/S sont décrites dans le Guide du langage Delphi". Cela n'aide pas beaucoup, puisque CodeGear n'a jamais fourni de guide de langue, et que la dernière fois que Borland en a fourni un, c'était pour Delphi 5.

Quelles fonctions et classes se comportent différemment sous {$I-} ?

---

EDITAR: La réponse acceptée donne un bon aperçu du contexte, mais voici un résumé rapide sous forme de liste alphabétique : {$IOCHECKS OFF} sólo affecte les routines suivantes de l'unité Système.

• Ajouter
• BlockRead
• BlockWrite
• ChDir
• CloseFile
• Eof
• Eoln
• Effacer
• FilePos
• Taille du fichier
• Chasse d'eau
• MkDir
• Lire
• Readln
• Renommer
• Réinitialiser
• Réécriture
• RmDir
• Cherchez
• Recherche de
• SeekEoln
• SetLineBreakStyle
• Tronquer
• Écrire à
• Écrivez à

Answer 1

Depuis $I est une directive du compilateur, elle ne peut affecter que le code généré par le compilateur, et elle ne peut affecter que le code qui est effectivement compilé.

Pour ces deux raisons, il ne peut pas affectent des choses comme TFileStream . C'est un cours de Classes.pas qui est une unité que vous ne compilez pas. Tout code qui s'y trouve n'est pas affecté par le $I . De plus, le compilateur ne traite pas cette classe de manière particulière. C'est juste une autre classe ordinaire.

Le site $I affecte les fonctions intégrées au langage que vous avez mentionnées. Le compilateur génère spécialement les appels à ces fonctions. Elle affecte également les appels à write , writeln y readln . Il devrait également affecter BlockRead y BlockWrite .

Vous pouvez vérifier le code source. Tout ce qui appelle SetInOutRes est susceptible de $I . Cela inclut les fonctions qui ouvrent des fichiers ( Append , Reset y Rewrite ), ainsi que tout ce qui accepte un paramètre de type file o TextFile ( Flush , BlockRead , BlockWrite , Erase , FilePos , Seek , FileSize , Read , Readln , Write , Writeln , Rename , Eof , SeekEof , Eoln , SeekEol , Truncate , SetLineBreakStyle y CloseFile ). De même, tout ce qui appelle InOutError ( ChDir , MkDir , amd RmDir ).

L'absence notable de la liste est AssignFile . Cette fonction ne fait pas réellement d'entrée/sortie. Elle configure simplement l'enregistrement du fichier de sorte que Append , Reset y Rewrite saura ce qu'il faut faire.

---

Je dois préciser que l'examen du code source n'est qu'une déduction. Le site $I permet de contrôler si le compilateur insère des appels à la directive __IOTest dans votre propre code après avoir appelé certaines autres fonctions. Cette fonction vérifie la valeur de InOutRes et s'il n'est pas égal à zéro, il déclenche une erreur d'exécution (qui peut donner lieu à une exception si la valeur de l'erreur est supérieure à zéro). SysUtils est inclus dans votre programme). Nous ne pouvons pas vérifier le code source pour directement trouver quelles fonctions sont affectées par $I (puisqu'elle n'est appelée que dans le code généré par le compilateur), nous cherchons donc simplement à savoir quelles fonctions set InOutRes en partant du principe qu'ils ne prendraient pas la peine de le faire s'ils ne savaient pas que le compilateur le vérifierait par la suite.