Discussion :

[exe2bin]

Bonsoir , je désire lire un fichier entièrement avec une fonction qui ne s'arrête pas après une fin de ligne ....
Je m'y perd entre flets(),fscanf() et autres fwrite() ?!

[edgarjacobs]

Hello,

C'est un peu vague comme demande. Pourquoi ne pas ouvrir le fichier mode binaire, tout simplement ?

[Bousk]

fopen
fseek
ftell
rewind
fread

[Sve@r]

Bonjour

Je m'y perd entre flets(),fscanf() et autres fwrite() ?!

C'est parce que mis à part fwrite() dédié à l'écriture, les autres fonctions que tu cites (fgets() et fscanf()) sont des fonctions dédiées à la lecture de ligne. Donc ces fonctions s'occupent en priorité du '\n' terminant la ligne.

Si tu veux lire un fichier sans prendre en compte la fin de ligne, faut utiliser des fonctions qui ne la prennent pas en compte (et là avoir une bonne connaissance des fonctions disponibles et de leur utilisation est alors un gros avantage). De fait tu peux utiliser au choix fgetc() qui lit un caractère ou bien fread() qui lit d'un coup un bloc de n octets.
Exemple de lecture de tout un fichier en utilisant fgetc

Code c :

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

1
2
3
4
5
6
7
8
int main() {
	FILE *fp;
	int c;
	fp=fopen(..., "r");
	while ((c=fgetc(fp)) != EOF)
		fputc(c, stdout);
	fclose(fp);
}

Exemple de lecture de tout un fichier en utilisant fread

Code c :

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

1
2
3
4
5
6
7
8
9
int main() {
	FILE *fp;
	char data[1000];
	int nb_lu;
	fp=fopen(..., "r");
	while ((nb_lu=fread(data, sizeof(char), 1000, fp)) > 0)
		fwrite(data, sizeof(char), nb_lu, stdout);
	fclose(fp);
}

Au résultat (affichage du fichier à l'écran) ces deux codes semblent identiques et même semblent identiques à un 3° qui lirait le fichier ligne par ligne. Mais si tu rajoutes un affichage particulier dans la boucle tu verras alors que cet affichage particulier se produit sans forcément qu'une fin de ligne soit atteinte...

PS: et si tu ouvres le fichier en mode "bas niveau" (avec "open" au lieu de "fopen") tu as alors read() qui est analogue à fread())

Pourquoi ne pas ouvrir le fichier mode binaire, tout simplement ?

Déjà le mode binaire n'existe pas sur les systèmes unix/linux car la distinction "binaire/texte" n'est qu'une distinction humaine et donc totalement hors des préoccupations de cet OS. Et d'ailleurs si tu réfléchis bien, tu réaliseras alors que cette distinction n'est qu'illusoire et qu'il n'existe en réalité aucune différence entre un fichier qui ne contient que des caractères affichables à l'écran (définition d'un fichier "texte") et un fichier qui contient tous les caractères de la gamme ascii (définition d'un fichier "binaire"). Et donc, de même qu'un carré n'est en réalité qu'un banal losange qui a juste une caractéristique supplémentaire (diagonales de mêmes longueurs), on peut dire qu'un fichier texte n'est aussi qu'un banal fichier binaire qui a juste une caractéristique supplémentaire (gamme de caractères réduite).
Et en réalité, ce mode d'ouverture binaire sous zindow n'influe absolument pas sur la façon de lire le fichier. La seule chose qui se passe, c'est que sous zindow une ouverture en mode dit "texte" converti alors tout caractère '\n' terminant une ligne en ce doublon de merde '\r\n' définissant une fin de ligne à la mode zindow (encore une fois bravo à eux pour leur inventivité de chiotte) ; tandis qu'une ouverture en mode dit "binaire" ne fait aucune conversion.
Mais dans les deux cas, les fonctions fgets() et ses consoeurs s'arrêtent quand-même au '\n'.

[Médinoc]

Tant de rage... Tu sais que le \r\n date de longtemps avant UNIX, non? C'est UNIX le special snowflake ici, pas Windows.
Microsoft n'a fait qu'assurer la compatibilité avec les OS antérieurs.

[Sve@r]

Tu sais que le \r\n date de longtemps avant UNIX, non?

Ouais, il date des machines à écrire style 1940. Quand il fallait appuyer sur le levier pour
1) faire revenir le charriot (\r) d'où est tiré le terme "retour charriot" symbolisant le <return> d'aujourd'hui
2) faire avancer le papier (\n)
Alors certes sur ce matériel cela se justifiait (on pouvait par exemple dans certains cas faire revenir le charriot sans faire avancer le papier pour par exemple réécrire en blanc et ainsi effacer une erreur) mais en informatique je vois mal ce qui justifie qu'une symbolique (représenter une fin de ligne dans un fichier) soit traduit par deux items. Ceci dit ce n'est pas la seule incompréhension à laquelle je suis confronté (je n'ai par exemple jamais réussi à faire le lien entre le fait que mettre une étiquette sur son bagage fera qu'il ne sera pas traité comme bagage abandonné). Maintenant si tu as l'explication pour l'une ou l'autre...

Tant de rage

Non t'as raison. C'est trop agréable d'ouvrir son fichier texte avec blocnote et de voir une seule énorme ligne parce que t'as oublié de cocher "ascii" lors de ton transfert ftp (ou toute autre raison comme un transfert par clef USB) et de devoir recommencer (et ne me parle pas de notepad++ car tu ne connais pas mes impératifs comme par exemple de travailler sur un réseau fermé sur l'ordi d'un tiers qui n'a évidemment donc pas ce merveilleux outil).

C'est UNIX le special snowflake ici, pas Windows.

Non ? Sans déconner ? Donc ce que tu me dis c'est que les codeurs d'Unix ont eu le courage d'affronter ce problème dès le départ au lieu de le laisser s'amplifier ? Ben j'apprécie ton info tout autant que leur audace.

Microsoft n'a fait qu'assurer la compatibilité avec les OS antérieurs.

Antiques. Le bon adjectif pour cette phrase c'est "antique". Microsoft n'a fait qu'assurer la compatibilité avec les OS antiques. Surtout qu'Unix (1970) est antérieur à MsDos (1981).

[Kannagi]

Microsoft n'a fait qu'assurer la compatibilité avec les OS antérieurs.

C'est peut être le ça le souci justement ^^'
Le BIOS a des interruptions obsolète (comme lancer un interpréteur Basic qui n’existe plus ou utiliser un mode VGA en 256 couleurs !)
On peut aussi parler que les failles Meltdown et Spectre sont aussi du a une volonté d'intel de garder une certaine compatibilité avec le fonctionnement des processeurs plus ancien et donc d'utiliser tout un arsenal pour rester compatible.
Pareil pour OpenGL qui a gardé sa compatibilité était sa plus grande faiblesse , d’où l'apparition du Vulkan qui est plus à jour sur le fonctionnement de nos GPU moderne.
Tout les format PE possède une entête MS-DOS qui est totalement inutile

Bref je pourrais continuer comme ça longtemps , la compatibilité c'est souvent un moins sur le long terme parce que rester compatible avec des technologies du passé est plus un frein qu'autre chose.

[Bktero]

Ouais, il date des machines à écrire style 1940

Dont on se traine aussi le mapping clavier tout pourri donc le placement touches t'empêchent de taper trop vite pour que les piges ne se croisent pas... Et je crois que tout le monde à ce mapping pourrir (BEPO, tu sors, personne ne te connait !).

Antiques. Le bon adjectif pour cette phrase c'est "antique". Microsoft n'a fait qu'assurer la compatibilité avec les OS antiques. Surtout qu'Unix (1970) est antérieur à MsDos (1981).

Antiques en 2018. Récents en 1981.

Bref je pourrais continuer comme ça longtemps , la compatibilité c'est souvent un moins sur le long terme parce que rester compatible avec des technologies du passé est plus un frein qu'autre chose.

Pourtant, les gens hurlent quand on casse la compatibilité...

[Médinoc]

Entre les machines à écrire et les fichiers, il y a eu les imprimantes, celles qui n'étaient pas "page par page".
Y compris celles qui servaient de sortie de terminal, avant que les sorties sur écran soient à la mode.

Et en plus des fichiers, il y a eu les protocoles de communication "basés sur le texte" qui utilisent spécifiquement des CRLF, comme telnet (1969, mis à jour en 1983), HTTP (1989), TFTP (1980), SMTP (1983)

Quand aux "OS antiques", CP/M fut créé en 1974 et maintenu jusqu'en 1983, et déployé sur pratiquement tout ce qui utilisait un processeur 8080, 8085 ou Z80. Une grosse partie des choses "reprochées" par les linuxiens à DOS viennent de la compatibilité avec CP/M, dont l'usage du CR+LF.

Et tiens, tant que j'y suis: Why is the line terminator CR+LF? (et une version où le lien à la fin marche)

[Sve@r]

Et tiens, tant que j'y suis: Why is the line terminator CR+LF? (et une version où le lien à la fin marche)

Bravo. Je m'incline. Le CRLF est la norme et donc doit être appliqué et contre ça on n'a rien à dire (même si je continue à ne pas comprendre les raisons qui ont amené cette décision). Je voulais rajouter un truc sur la différence bin/ascii mais je réalise que si tout le monde appliquait la norme, il n'y aurait alors là non plus plus de souci.