Discussion :

[naute]

Bonjour .

J'ai besoin d'utiliser les techniques d'allocation dynamique de mémoire pour travailler sur des chaînes de caractères dans des programmes C. Mes connaissances en C étant très limitées, je fais des tests et je consulte les tutoriels traitant de ce sujet.
Je butte actuellement sur deux problèmes :

1. Le premier problème vient d'un fragment de code issu du tutoriel Description des mécanismes d'allocation dynamique de mémoire en langage C :
   

   Code C :

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

   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   14
    
   int * temp;
   temp = realloc (tabentier, 4 * sizeof(int) );
    
   if ( temp == NULL )
   {
        fprintf(stderr,"Reallocation impossible");
        free(tabentier);
        exit(EXIT_FAILURE);
   }
   else
   {
        tabentier = temp;
   }

   Si on libère le pointeur "tabentier" en cas de réallocation impossible, les données sur lesquelles il pointait deviennent inaccessibles. Le fait de passer par un pointeur temporaire pour protéger "tabentier" ne sert donc plus à rien. D'autre part, si l'allocation réussit, une fois que "tabentier" a pris la valeur "temp", que devient son ancienne adresse mémoire ?
2. Le second problème concerne ce bout de code venant de mes tests :
   

   Code C :

   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
   27
   28
   29
   30
   31
   32
   33
   34
   35
   36
   37
   38
    
   #include <stdio.h>
   #include <stdlib.h>
   #include <string.h>
    
   int main()
   {
     unsigned char *reception = NULL;  // Caractères ASCII de 0 à 255
     int taille = 50;
     int nbCar;
     reception = malloc(taille); // Allocation de la mémoire
     if (reception == NULL)
     {
       exit(0);
     }
     for (int i = 0; i < taille; i++)
     {
       reception[i] = NULL;
     }
     reception[taille -1] = '\0';
     printf("L'adresse mémoire est %d\n", reception);
     printf("sizeof(*reception) = %i\n", sizeof(*reception));
     printf("sizeof(reception) = %i\n", sizeof(reception));
     printf("Le contenu de \"réception\" est \"%d\"\n", *reception);
     printf("Saisissez une chaîne : ");
     scanf("%s", reception);
     nbCar = strlen(reception);
     reception[nbCar] = '\0';  //  Ajout du caractère de fin de chaîne
     printf("Vous avez saisi \"%s\"\n", reception);
     printf("La chaîne fait %d caractères\n", nbCar);
     for (int i = 0; i < nbCar; i++)
     {
       printf("Le caractère n° %d est : %c (ASCII %d)\n", i, reception[i], reception[i]);
     }
     free(reception);
     reception = NULL;
     return(0);
   }

   Si je saisi "Développez.com c'est cool !", voici ce que j'obtiens:
   
   Les deux points qui m'embêtent le plus sont :
   
   • pourquoi la chaîne est-elle coupée au niveau de l'espace ?
   • pourquoi le caractère accentué n'est-il pas reconnu quand j'affiche les caractères un par un alors qu'il l'est quand j'affiche la chaîne ?
   
   Pour info, le "é" de code ASCII 130 est toujours remplacé par les caractères de code ASCII 195 et 169, le "à" (133) sera remplacé par 195 et 160, le "ù" (151) par 195 et 185 etc.

Les explications sont peut-être très simples mais moi je me gratte la tête .

Si quelqu'un pouvait éclairer ma lanterne, ce serait super sympa.

Amicalement,
naute

[foetus]

Documentation de realloc en anglais
C'est la façon que travaille la fonction realloc
Si elle réussit à réallouer (ou allouer la première fois équivalent à 1 malloc) elle libère l'ancien emplacement et retourne l'adresse du nouvel emplacement. Sinon elle retourne NULL sans toucher à l'emplacement mémoire.
Ici en cas d'erreur tu libères l'emplacement parce que tu quittes le programme.

Documentation de scanf en anglais elle s'arrête dès le 1ier espace

Et également, la table des caractères ASCII va de 0 à 127, et non 255 . Donc les caractères au delà ne sont pas de l'ASCII (soit du MBCS, soit de l'Unicode (UTF-8 ou UTF-16)). C'est pour cela qu'ils ne s'affichent pas bien.
La console/ ligne de commandes sous Windows devient en 2020 Unicode, mais avant c'est du MBCS et donc il faut choisir le bon "codepage"


Édit : D'ailleurs as-tu remarqué que dans la librairie standard C, les caractères sont de type char Cela veut dire que ton entier est signé (dépend de ton compilateur mais à 98% sûr) donc une plage de valeurs de [-127, 127]
Ce qui n'est pas pratique lorsqu'on parse un fichier Unicode (UTF-8 ou UTF-16), qui lui, pour le coup, a des valeurs dans une plage [0, 255]

[naute]

Merci pour tes réponses et les liens .

elle libère l'ancien emplacement

J'étais passé à côté de ça. Donc OK pour realloc().

elle s'arrête dès le 1ier espace

Alors comment on fait quand on traite une chaîne comportant des espaces, ce qui est assez fréquent ?

Et également, la table des caractères ASCII va de 0 à 127, et non 255 . Donc les caractères au delà ne sont pas de l'ASCII (soit du MBCS, soit de l'Unicode (UTF-8 ou UTF-16)).

On entend pourtant assez souvent parler d'ASCII étendu, mais c'est vrai qu'à partir de 128, ce n'est plus standard.

C'est pour cela qu'ils ne s'affichent pas bien.

Je suis d'accord mais dans ce cas, pourquoi l'affichage est bon avec %s et pas avec %c ? Ce n'est pas très cohérent.

D'ailleurs as-tu remarqué que dans la librairie standard C, les caractères sont de type char

C'est la raison pour laquelle, naïvement, j'avais déclaré mon pointeur comme ça :

Code :

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

unsigned char *reception = NULL;  // Caractères ASCII de 0 à 255

Est-ce qu'on peut travailler en UTF-8 avec scanf() et printf() ?

[Sve@r]

Bonjour

Si on libère le pointeur "tabentier" en cas de réallocation impossible, les données sur lesquelles il pointait deviennent inaccessibles.

Pas tout à fait. la zone existe toujours en mémoire. Simplement elle est libre pour qui en aura besoin.

D'autre part, si l'allocation réussit, une fois que "tabentier" a pris la valeur "temp", que devient son ancienne adresse mémoire ?

Dans la réallocation (qui n'a de sens que si on agrandit la zone initiale), soit la partie "en plus" peut se greffer à la zone déjà alloué et rien de visible ne se passe (la zone initiale faisait "n" maintenant elle fait "m" et c'est tout), soit il faut tout mettre ailleurs et dans ce cas, la zone initiale est alors recopiée ailleurs. Et dans ce cas, la zone initiale est alors libérée pour quelqu'un d'autre.

En fait, pour bien comprendre malloc(), représente-toi la mémoire comme une immense suite de cases. malloc() c'est juste un truc qui en prend une presque au hasard et qui dit à l'OS "ok, donc maintenant depuis cette case jusqu'à n tout est à moi". Soit l'OS dit "ok" et malloc() te renvoie l'adresse de ladite case (et comme tu connais "n" vu que c'est toi qui l'a demandé t'as alors tout en main pour bien gérer ta zone) ; soit l'OS dit "je peux pas parce que je suis raide en ce moment" et malloc() te renvoie NULL et positionne la variable globale "errno" avec la cause du souci. Et si tu affiches la string renvoyée par strerror(errno) tu auras alors la cause donnée par l'OS.

pourquoi la chaîne est-elle coupée au niveau de l'espace ?

C'est le fonctionnement de scanf() qui utilise l'espace pour se repérer. Te faut passer par fgets() si tu veux tout récupérer.

pourquoi le caractère accentué n'est-il pas reconnu quand j'affiche les caractères un par un alors qu'il l'est quand j'affiche la chaîne ?

Souci d'encoding. En utf8 (qui est maintenant standard), un caractère accentué fait 2 octets. Le format "%s" sait le prendre en compte mais pas le "%c".

Sinon quelques erreurs dans ton code
1) reception[i]=NULL => NULL est une valeur de pointeur et reception[i] est un char. Même si à la base tout est nombre et qu'on peut parfaitement copier un pointeur NULL dans un char/int (cast implicite), vaut mieux écrire une valeur dédiée aux char/int => reception[i]='\0' ou reception[i]=0. Et dans ce cas, tu vois que reception[taille -1] = '\0' du dessous devient inutile. Et (si on élargit le débat), cette partie d'initialisation est en réalité totalement inutile vu que tu vas écraser la zone initialisée par ta saisie (enfin c'est ma façon de voir mais d'autres intervenant te diront qu'initialiser systémétiquement te protège contre un oubli).
Mais si vraiment tu veux initialiser, tu peux alors utiliser memset() qui fait la boucle à ta place.
2) tu n'as pas besoin de positionner le '\0' après la saisie. En effet, les fonctions de saisie de strings le mettent elles-même. D'autant plus que si tu le positionnes, ça veut dire que tu pars du principe qu'il n'y est pas. Mais s'il n'y est pas, tu n'as alors pas le droit d'utiliser des fonctions de lecture de string comme strlen() car ces fonctions utilisent justement le '\0' pour se repérer
3) attention à sizeof() car pour un pointeur, même un pointeur alloué, il te renvoie quand-même la taille du pointeur (4 ou 8 octets suivant que tu es en 32b ou 64b).

[foetus]

Quelques réponses

Est-ce qu'on peut travailler en UTF-8 avec scanf() et printf() ?

Il faut passer par le type wchar_t et la bibliothèque wchar.h (<- documentation cplusplus en anglais) avec les fonctions wscanf et wprintf.

Je suis d'accord mais dans ce cas, pourquoi l'affichage est bon avec %s et pas avec %c ?

Simple parce que ton caractère est sur plusieurs octets. Donc il faut lire tous les octets pour afficher le caractère correctement (sous Linux - ta capture - est en UTF-8 il me semble )
Édit : barbecued par @Sve@r

Est-ce qu'on peut travailler en UTF-8 ?

Par contre avec un fichier il n'y a pas de problème. avec les fonctions getc/ gets. Il faut caster en unsigned char et reconstitué les caractères si nécessaire.

[naute]

Bonjour Sve@r .

Pas tout à fait. la zone existe toujours en mémoire. Simplement elle est libre pour qui en aura besoin.

Je me suis mal exprimé : je voulais dire qu'elle était devenue inaccessible pour le programme. Cela dit, puisqu'on le quitte, ça n'a plus d'importance.

Dans la réallocation (qui n'a de sens que si on agrandit la zone initiale), soit la partie "en plus" peut se greffer à la zone déjà alloué et rien de visible ne se passe (la zone initiale faisait "n" maintenant elle fait "m" et c'est tout), soit il faut tout mettre ailleurs et dans ce cas, la zone initiale est alors recopiée ailleurs.

Compris

Et dans ce cas, la zone initiale est alors libérée pour quelqu'un d'autre.

Ça rejoint ce que disais foetus.

En fait, pour bien comprendre malloc(), représente-toi la mémoire comme une immense suite de cases
.../...
Et si tu affiches la string renvoyée par strerror(errno) tu auras alors la cause donnée par l'OS.

OK. J'ai parfois une adresse mémoire négative : ça correspond à quoi ?

C'est le fonctionnement de scanf() qui utilise l'espace pour se repérer. Te faut passer par fgets() si tu veux tout récupérer.

J'ai essayé avec :

Code c :

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

gets(reception);

ça fonctionne mais gare aux débordements.
Je ne vois pas comment utiliser fgets() dans mon cas (avec l'entrée standard).

Souci d'encoding. En utf8 (qui est maintenant standard), un caractère accentué fait 2 octets. Le format "%s" sait le prendre en compte mais pas le "%c".

C'est tout à fait logique. J'aurai dû y penser .

Sinon quelques erreurs dans ton code...

Je vais modifier mon code en tenant compte de tes remarques.

3) attention à sizeof() car pour un pointeur, même un pointeur alloué, il te renvoie quand-même la taille du pointeur (4 ou 8 octets suivant que tu es en 32b ou 64b).

Là je ne pige pas trop. Est-ce que ça veut dire que quand tu demandes une allocation mémoire pour un char, du genre :

Code c :

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

reception = malloc(1 * sizeof(char));

donc 1 octet, on te réserve 8 octets ?


@foetus

Simple parce que ton caractère est sur plusieurs octets. Donc il faut lire tous les octets pour afficher le caractère correctement (sous Linux - ta capture - est en UTF-8 il me semble )

Trop tard .

Par contre avec un fichier il n'y a pas de problème. avec les fonctions getc/ gets. Il faut caster en unsigned char et reconstitué les caractères si nécessaire.

gets() est vu plus haut, quant à getc(), il pose le même problème que fgets(). Je ne lis pas depuis un fichier.
Je vais également aller voir du côté de getchar().

En tous cas, merci pour vos conseils. Il me font bien avancer.

À bientôt,
naute

[foetus]

OK. J'ai parfois une adresse mémoire négative : ça correspond à quoi ?

Au format printf (<- lien cplusplus en anglais avec tous les formats)

%d c'est pour 1 entier signé, %u pour 1 entier non signé et surtout %p pour une adresse mémoire.

Là je ne pige pas trop. Est-ce que ça veut dire que quand tu demandes une allocation mémoire pour un char

Tu n'as pas compris
Le nombre d’adresses mémoire dépend du nombre de bits du processeur. Un processeur X bits peut allouer au plus 2^(X / 8) octets, donc une plage d’adresses [0, 2^(X / 8) - 1].
Et donc lorsque tu prends la taille d'un pointeur avec sizeof, c'est toujours soit 4 octets (pour un processeur 32 bits) soit 8 octets (pour un processeur 64 bits, mais la mémoire est limitée à 48 il me semble ).

Après, cela va dépendre de ton système d'exploitation du nombre d'octets qu'il va allouer pour tel ou tel malloc (et effectivement il peut y avoir éventuellement de l'alignement mémoire, lien wiki en français)

[Christophe]

gets() est vu plus haut, quant à getc(), il pose le même problème que fgets(). Je ne lis pas depuis un fichier.

Sous Unix, tout est fichier. Tu peux lire la console comme un fichier dont le handle se nomme stdin.

gets peut être vu comme un équivalent de fgets sur le fichier stdin mais sans contrôle de débordement.
gets lira la chaine jusqu'à un retour chariot (ou EOF), il ne s'occupera pas de la taille du buffer. fgets lira jusqu'à un retour chariot, ou le nombre max passé en paramètre. fgets stocke le retour chariot dans la chaine contrairement à gets.

[naute]

Bonjour .

@foetus

Au format .../... et surtout %p pour une adresse mémoire.

Effectivement, là il n'y a plus d'ambiguïté.

Tu n'as pas compris

Je sais bien . C'est pour ça que je suis ici . Mais j'me soigne .
Ah ! le bon vieux temps du mode réel et des segments de 64 K .

@chrtophe

Sous Unix, tout est fichier. Tu peux lire la console comme un fichier dont le handle se nomme stdin.

Très juste ! Effectivement, comme ça, fgets() fonctionne sans problème .

Avec les bonnes explications, on finit par y arriver .

à vous deux,
amicalement,
naute

[Sve@r]

Cela dit, puisqu'on le quitte, ça n'a plus d'importance.

Exactement. Très bonne philosophie. Quand on ferme/quitte/libère un truc, faut pas se préoccuper de ce que devient le truc puisqu'on ne s'en sert plus.

OK. J'ai parfois une adresse mémoire négative : ça correspond à quoi ?

Erreur de format d'affichage. Tu dois utiliser "%d" alors qu'il vaudrait mieux utiliser "%lu" ou mieux "%x" (ou "%p"). J'ai justement écrit un petit truc à ce propos ici.

J'ai essayé avec :

Code c :

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

gets(reception);

ça fonctionne mais gare aux débordements.

Oui. Ton compilateur a même dû te dire que gets() est dangereuse. Pour des tests rapides et temporaires pas de souci mais pour un projet ops, faut la bannir.

Là je ne pige pas trop. Est-ce que ça veut dire que quand tu demandes une allocation mémoire pour un char, du genre :

Code c :

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

reception = malloc(1 * sizeof(char));

donc 1 octet, on te réserve 8 octets ?

Non.

Déjà demander une allocation de 1 (ou 10 ou 50 ou 5000) est inutile. Tu veux 1, tu définis un char. Tu veux 10 ou 50 ou 5000 tu définis un tableau. malloc() ne s'utilisera que si tu ne connais pas la taille à l'avance au moment où tu écris ton code (taille calculée, lue dans un fichier, etc).

Mais ce que je voulais dire, c'est que sizeof(x) (VF "taille de x") donne juste et uniquement la taille de la variable "x", rien de plus. Et il ne se préoccupe absolument pas de savoir si "x" référence une zone allouée ou quoi que ce soit d'autre.
Donc ton pointeur int * temp c'est déjà en lui-même un espace mémoire. Espace pour stocker une adresse. Tout comme quand tu définis double d tu définis une variable"d" ayant une taille suffisante pour stocker un double, quand tu écris int * temp c'est la même chose, tu définis une variable "temp" ayant une taille suffisante pour stocker un int étoile (l'adresse d'un int). Et quand on parle d'OS 64 bits, ça veut dire qu'on parle d'OS ayant des adresses sur 64 bits (donc sur 8 octets). Donc "temp" fait 8 octets (comme un double).
L'usage est d'ailleurs de coller l'étoile d'un côté ou de l'autre, pas de la laisser au milieu comme une bouse. Soit tu écris int *temp soulignant par là que tu privilégies l'entier "*temp", soit tu écris int* temp, soulignant que tu privilégies l'adresse "temp". Dans tous les cas pour le compilateur c'est pareil, et dans tous les cas tu peux travailler avec "temp" comme avec "*temp". C'est juste une astuce pour aider à la relecture.

[naute]

Bonsoir Sve@r .

Erreur de format d'affichage. Tu dois utiliser "%d" alors qu'il vaudrait mieux utiliser "%lu" ou mieux "%x" (ou "%p"). J'ai justement écrit un petit truc à ce propos ici.

J'ai suivi ton lien : excellente explication ! ce que j'en retiens surtout, c'est qu'il faut bien faire le distinguo entre la valeur et la manière dont on l'affiche.

Oui. Ton compilateur a même dû te dire que gets() est dangereuse. Pour des tests rapides et temporaires pas de souci mais pour un projet ops, faut la bannir.

Tout à fait. Je compile avec GCC sous code::blocks et j'ai droit à mon petit rectangle rouge .

Mais ce que je voulais dire, c'est que sizeof(x) (VF "taille de x") donne juste et uniquement la taille de la variable "x", rien de plus. Et il ne se préoccupe absolument pas de savoir si "x" référence une zone allouée ou quoi que ce soit d'autre.

OK, pigé !

L'usage est d'ailleurs de coller l'étoile d'un côté ou de l'autre, pas de la laisser au milieu comme une bouse.

Cette écriture n'est pas de mon fait. Elle provient du tutoriel dont je parle en début de post. Personnellement, je privilégie l'écriture int *temp; qui permet notamment de déclarer plusieurs pointeurs sur la même ligne comme int *temp1, *temp2;.


Merci pour ce complément d'information ,
amicalement,
naute