Que faire lors d'un malloc qui retourne NULL en langage C?, Stratégie de contournement d'erreur.

[macuserfr]

Bonsoir à tous,
J'suis en train d'étudier le langage C. J'ai pris conscience qu'il faut vérifier les sources d'erreur comme les malloc. Mais que faire si un malloc échoue? Simplement faire un printf("erreur"); et quitter ne me convient pas, je cherche quelque chose de plus élégant.
Est-ce que:

CODE

do toto = (char *) malloc( sizeof(char) * 32 );
while(toto==NULL);

serait trop bourrin pour garantir une allocation mémoire à tout prix?
Qu'elles sont vos stratégies? Comment contournez-vous ce problème pour continuer le programme normalement?

Désolé de la question existentielle de néophite mais ça me démange. À vos claviers, je vous écoute

Ce message a été modifié par macuserfr - 6 Nov 2006, 23:22.

[cuzub]

Tu ne sembles pas utiliser malloc de la bonne manière : malloc va allouer de la mémoire en fonction de ce que tu lui donnes en argument:

par ex :

char *c = (char *) malloc( sizeof(char) * 32 );

alloue une chaine de 32 caractères (en passant sizeof(char) ne sert pas à grand chose puisque cela retourne 1 mais bon, ca fait plus propre)

Il faut donc que tu indiques à malloc la taille de la mémoire à allouer.
malloc te retourne alors un pointeur sur cet espace mémoire alloué.

ne pas oublier de faire un free(pointeur) lorsque tu as terminé.

[macuserfr]

Oui, ça je sais, j'avais mis un schéma simplifié, l'important n'était pas l'appel à malloc mais la boucle, je vais éditer mon post pour pas laisser d'ambiguité mais je n'ai pas de problème particulier à allouer de la mémoire. Ce que je me (vous) demande c'est quoi faire quand ça plante?
Merci quand même pour répondre promptement

[guerom00]

Ne peux-tu pas tester si ta quantité est allouée ?

[Doom Hammer]

http://forum.macbidouille.com/index.php?showtopic=190158
En général si malloc échoue c'est mal barré. Ça indique la terminaison futur du programme de façon assez rapide.
En vérifiant les cas d'erreurs tu peux afficher un joli message d'erreur pour exposer le problème à l'utilisateur, éventuellement (tenter de) sauver le document en cours etc... puis quitter.

Ce message a été modifié par Doom Hammer - 6 Nov 2006, 23:39.

[macuserfr]

Quand il retourne NULL c'est que la quantité n'est pas allouée. Le test est déjà fait. Ce que je démande c'est quoi faire lorsque ce teste donne négatif. Hurler? Casser l'ordinateur? Se jeter par la fenêtre?

Merci Doom pour la réponse, bien que j'avoue être frustré de pas pouvoir faire grand chose pour mon programme. Je m'y attendai à un bout de code magique qui rattraperai la donne... Mais apparement le mieux qu'on puisse faire c'est dire au revoir et quitter.

Ce message a été modifié par macuserfr - 6 Nov 2006, 23:46.

[schlum]

Tu peux en général écrire des données déjà allouées sur le disque (attention, en bas niveau : fwrite, sinon il risque d'avoir besoin d'allouer autre chose... !).
Après, c'est "les femmes et les enfants d'abord"

[noop]

Un NULL retourné par un malloc() est une situation desespérée (a moins que tu demande des méga et des mégas de mémoire).

Il y a de forte chance pour que ta machine plante assez vite entrainant ton programme dans les bas fond des kernel panic.

Ma solution: ne pas tester les malloc pour des petites quantités de mémoire. Ne s'y interesser que quand tu demande des plages mémoire supérieures a 4096 octets (par exemple). A toi de définir ta limite.
Avantage:
ton code sera plus concis, plus lisible plus maintenable.

Ne cherche pas à être un ayatolah des règles de développement. Un peu de souplesse et de pragmatisme sont nécessaire en développement.

[chombier]

Un NULL retourné par un malloc() est une situation desespérée (a moins que tu demande des méga et des mégas de mémoire).

Il y a de forte chance pour que ta machine plante assez vite entrainant ton programme dans les bas fond des kernel panic.

Ma solution: ne pas tester les malloc pour des petites quantités de mémoire. Ne s'y interesser que quand tu demande des plages mémoire supérieures a 4096 octets (par exemple). A toi de définir ta limite.
Avantage:
ton code sera plus concis, plus lisible plus maintenable.

Ne cherche pas à être un ayatolah des règles de développement. Un peu de souplesse et de pragmatisme sont nécessaire en développement.

c'te bonne blague...
signé: un ayatollah...

[schlum]

Et ça recommence...

[Cochonou]

Il faudrait ajouter un point dans la charte indiquant que les sujets traitant de malloc sont trop polémiques, et donc interdits.

[noop]

Il faudrait ajouter un point dans la charte indiquant que les sujets traitant de malloc sont trop polémiques, et donc interdits.

...ajoute aussi calloc(), realloc()..

[roseau]

en fait la seul chose que tu ais à faire c'est intercepter l'erreur et la traiter, ça peut être par un vidage de la mémoire et donc crash de l'application en cours sans conséquence sur le reste du système, soit tu rectifies en essayant d'autres méthodes d'allocation de mémoire car de toute manière attendre que la mémoire soit libérée pour la prendre relève de l'utopie

par exemple en utilisant un fichier temporaire pour stocker des infos, ça se fait beaucoup en BD où tu as quelques fois besoin de tellement de mémoire pour lire les données que tu n'arrives jamais à l'obtenir et donc la seul solution c'est le fichier sur un disque

[macuserfr]

Merci Roseau.
Donc apparement malloc rend rarement un pointeur NULL, heureusement. Faut en demander beaucoup pour qu'il échoue. Mais refaire une allocation est si utopiste que ça? le do while de mon premier post rentrerai en boucle infinie?

Sinon sur mon projet actuel je doit avouer que j'ai incriminé malloc trop vite, j'avait un pointeur declaré mais pas affecté (aie, pas tapper!) qui trainait. J'avai de la chance que la mémoire allouée par malloc était souvent à zéro, donc ce pointeur avait pour adresse NULL (0x00). Mais dès que le malloc rendait autre chose que de la mémoire "vierge" ce pointeur allait tapper dans une adresse interdite... Et ça, forcément, ça fait une belle erreur de segmentation.

Je me suis aperçu du problème sous linux où dès la première affectation le pointeur avait une adresse quelconque et plantait. Vive gdb!

[roseau]

Merci Roseau.
Donc apparement malloc rend rarement un pointeur NULL, heureusement. Faut en demander beaucoup pour qu'il échoue. Mais refaire une allocation est si utopiste que ça? le do while de mon premier post rentrerai en boucle infinie?

Sinon sur mon projet actuel je doit avouer que j'ai incriminé malloc trop vite, j'avait un pointeur declaré mais pas affecté (aie, pas tapper!) qui trainait. J'avai de la chance que la mémoire allouée par malloc était souvent à zéro, donc ce pointeur avait pour adresse NULL (0x00). Mais dès que le malloc rendait autre chose que de la mémoire "vierge" ce pointeur allait tapper dans une adresse interdite... Et ça, forcément, ça fait une belle erreur de segmentation.

Je me suis aperçu du problème sous linux où dès la première affectation le pointeur avait une adresse quelconque et plantait. Vive gdb!

tu me donnes l'impression de développer un peu au hasard non?

[macuserfr]

tu me donnes l'impression de développer un peu au hasard non?

Le hasard fait bien les choses, non?
Non, en fait ce qui s'est passé c'est que ça faisait un an que je touchais pas au C et que j'ai pondu 900 lignes de code en une semaine... Forcément la vitesse et la précision vont pas trop ensemble.

[noop]

J'avai de la chance que la mémoire allouée par malloc était souvent à zéro, donc ce pointeur avait pour adresse NULL (0x00). Mais dès que le malloc rendait autre chose que de la mémoire "vierge" ce pointeur allait tapper dans une adresse interdite... Et ça, forcément, ça fait une belle erreur de segmentation.

La chance c'était que tu sois en mode débug. Dans ce cas la mémoire est allouée est mise a zéro. Quand tu enlève les options de debug a la compil, la mémoire allouée contient n'importe quoi. Et on se trouve devant le cas du programme marche en debug et pas en mode "release"

Ce message a été modifié par noop - 7 Nov 2006, 15:24.

[macuserfr]

Non, sous Mac OS X, même compilé en mode "release" (gcc -o Program main.c -Wall -ansi dans le terminal) ça passait "à peu près". C'est sous linux x86 à la fac que ça crash direct.