Quelle est la valeur des compilateurs "\ n" sous C pour les anciens Mac OS?

Question

Arrière-plan:

Dans les versions de Mac OS jusqu'à la version 9, la représentation standard pour les fichiers texte utilisés ASCII CR (retour chariot) de caractères, la valeur décimale 13, pour marquer la fin d'une ligne.

Mac OS 10, à la différence des versions précédentes, est de type UNIX, et utilise le code ASCII du caractère LF (saut de ligne) de caractères, la valeur décimale 10, pour marquer la fin d'une ligne.

La question est de savoir, quelles sont les valeurs des constantes de caractères '\n' et '\r' dans les compilateurs C et C++ pour Mac OS versions antérieures d'OS X?

Il y a (au moins) deux approches possibles qui pourraient avoir été prises:

1. Traiter '\n' que l'ASCII LF personnage, et de le convertir et de CR de la sortie et d'entrée de texte ruisseaux (similaire à la conversion entre LF et CR-LF sur les systèmes Windows); ou
2. Traiter '\n' que l'ASCII CR caractère, qui ne nécessite pas de conversion en entrée ou en sortie.

Il y aurait des problèmes potentiels avec la deuxième approche. L'une est que le code qui suppose '\n' LF risque d'échouer. (Ce code est intrinsèquement non-portable, de toute façon.) L'autre est qu'il y a encore besoin d'être une valeur distincte pour '\r', et sur une base ASCII système CR est la seule raisonnable de la valeur. Et le C standard ne permet pas de se '\n' == '\r' (grâce à mafso pour trouver la citation, 5.2.2 paragraphe 3), de sorte que certains autres de la valeur devra être utilisé pour l' '\r'.

Qu'est-ce que la sortie de ce programme C lorsqu'il est compilé et exécuté sous Mac OS N, pour N inférieur à 10?

#include <stdio.h>
int main(void) {
    printf("'\\n' = %d\n", '\n');
    printf("'\\r' = %d\n", '\r');
    if ('\n' == '\r') {
        printf("Hmm, this could be a problem\n");
    }
}

La question s'applique à la fois le C et le C++. Je suppose que la réponse serait la même pour les deux.

La réponse pourrait également varier d'un compilateur C pour un autre, mais j'espère que les responsables de l'implémentation du compilateur aurait maintenu la cohérence les uns avec les autres.

Pour être clair, je ne demande pas quelle représentation les anciennes versions de Mac OS utilisé pour représenter de fin de ligne dans les fichiers texte. Ma question est spécifiquement et uniquement sur les valeurs des constantes '\n' et '\r' en C ou C++ code source. Je suis conscient que l'imprimerie '\n' (quelle que soit sa valeur) à un flux de texte provoque la conversion du système de fin de ligne de la représentation (dans ce cas, ASCII CR); ce comportement est requis par la norme.

Answer 1

Les valeurs des constantes de caractères \r et \n a été exactement la même en Classique les environnements Mac OS comme il a été partout ailleurs: \r a été CR a été ASCII 13 (0x0d); \n a été LF a été ASCII 10 (0x0a). La seule chose qui était différente sur le Classique de Mac OS était qu' \r a été utilisé comme la "norme" de fin de ligne dans les éditeurs de texte, comme \n est utilisé sur les systèmes UNIX, ou \r\n sur le DOS et les systèmes Windows.

Voici une capture d'écran d'un simple test de programme en cours d'exécution dans Metrowerks CodeWarrior sur Mac OS 9, par exemple:

Gardez à l'esprit que Classique les systèmes Mac OS n'ont pas un système à l'échelle de bibliothèque standard C! Des fonctions comme printf() étaient présents que dans le cadre de compilateur des bibliothèques spécifiques comme les SIOUX pour CodeWarrior, qui a mis en place C standard I/O par l'écriture de la sortie vers une fenêtre avec un champ de texte dans il. En tant que tel, certaines implémentations de la norme e/S de fichier peut avoir réalisé des traductions automatiques \r et \n, qui peut être ce que vous pensez de. (De nombreux systèmes Windows faire des choses similaires pour \r\n si vous ne passez pas l' "b" le drapeau en fopen(), par exemple). Il n'y a certainement rien de tel que Mac OS boîte à outils, bien que.

Answer 2

J'ai fait une recherche et trouvé cette page avec une vieille discussion où ce sont surtout les éléments suivants peuvent être trouvés:

Le Metrowerks MacOS mise en œuvre va plus loin en l'inversion de la signification de la CR et LF à l'égard de le '\r' et '\n' échappe dans les e/s impliquant un fichier, mais pas dans un autre contexte. Cela signifie que si vous ouvrez un FICHIER ou fstream en mode texte, chaque '\r' seront de sortie y un LF ainsi que tous les '\n' étant sortie CR, et la même est vrai de l'entrée - l'évasion-à-ASCII binaire correspondances sont inversés. Ils ne sont pas inversées, cependant, dans la mémoire, par exemple avec sprintf() pour un tampon ou avec un std::stringstream. Je trouve cela déroutant et, si ce n'est pas standard, au moins pire que d'autres implémentations.

Il s'avère qu'il existe une solution de contournement avec MSL - si vous ouvrez le fichier en mode binaire puis '\n' toujours == LF et '\r' toujours == CR. C'est ce que je voulais, mais en se cette information j'ai aussi eu beaucoup de justification de les gens là-bas que c'était la "norme" de façon à obtenir ce que je voulais, quand je sens que c'est plus comme une solution de contournement pour un bug dans leur mise en œuvre. Après tout, CR et LF 7-bit ASCII des valeurs et je m'attends à être en mesure d'utiliser dans un façon standard avec un fichier ouvert en mode texte.

(Une réponse est clair que ce n'est en effet pas une violation de la norme).

Alors, évidemment, il y avait au moins une mise en œuvre qui a utilisé \n et \r à l'habitude des valeurs ASCII, mais traduit dans (non binaires) fichier de sortie (par juste de les échanger).

Answer 3

Sur les anciens compilateurs Mac, les rôles de \ r et \ n ont été inversés: nous avions "\ n" == 13 et "\ r" == 10, alors qu'aujourd'hui "\ n" == 10 et "\ r" == 13. Très amusant pendant la phase de transition. Ecrivez un '\ n' dans un fichier avec un ancien compilateur, lisez-le avec un nouveau compilateur et obtenez un '\ r' (bien sûr, les deux fois, vous aviez réellement un numéro 13).

Answer 4

C-spécification du langage:

5.2.2
...
2 Alphabétique des séquences d'échappement représentant les caractères non-imprimables dans l'exécution du jeu de caractères sont destinés à produire des actions sur des dispositifs d'affichage comme suit:
...
\n (nouvelle ligne) Déplace la position active à la position initiale de la ligne suivante.
\r (retour chariot) Déplace la position active à la position initiale de la ligne courante.

donc, \n correspond bien à la char dans l'encodage des caractères... en ASCII est l' LF char

Answer 5

Je n'ai pas un vieux Mac compilateur de vérifier si elles suivent, mais la valeur numérique de l' '\n' doit être le même que l'ASCII caractère de nouvelle ligne (étant donné que ces compilateurs utilisés ASCII compatible encoding comme l'exécution d'encodage, qui, je crois, ils l'ont fait). '\r' doivent avoir la même valeur numérique que le code ASCII du caractère de retour chariot.

La bibliothèque ou le système d'exploitation fonctions qui manipulent l'écriture d'un texte en mode fichiers est responsable de la conversion de la valeur numérique d' '\n' quelque soit le système d'exploitation utilise pour mettre fin à des lignes. Les valeurs numériques de ces personnages au moment de l'exécution sont entièrement déterminé par l'exécution de jeu de caractères.

Donc, puisque nous sommes encore en ASCII compatible exécution des codages les valeurs numériques doivent être les mêmes qu'avec les Mac classic compilateurs.