GCC 4.7.3 - Char problème de mémoire VS String ?

Bonjour,

Ayant de grosses difficultés de gestion mémoire due aux altération des emplacements en mémoire des autres variables avec char* et char[] et les manipulation de chaines, j'ai consulté cette petite documentation qui m'a un peu ouvert l'esprit sur mon problème, qu'apparemment char* et char[] ne devraient exister. C'est par ce qu'ils allouent une zone à la mémoire en mode Yoooooolooooooo ? (sans faire gaffe aux autres variables déjà définies en mémoire?)

Apparemment il serai plus efficace d'utiliser le type String que j'ai pas :calim2: "Error, String was not declared in this scope"
Je souhaiterai donc savoir si il existe une lib ou une include qui permettrai de supporter le type String sur GCC/DJGPP ?
La plateforme utilisé : FreeDos x86 en DPMI

Merci :-)

Bien le bonjour;

Sans plus m'avancer, j'ai l'impression que ton problème est surtout basé sur le C++ et non le C, je me trompe ?

Un string en tant que tel n'existe pas en C, c'est une conception bien trop haut niveau pour ce langage.
Il y a, sur dvp, l'ami franckh qui présente ici sa librairie de gestions de chaine de caractère : http://franckh.developpez.com/cstr/

Ah oui effectivement...
Merci pour le lien je vais jeter un coup d’œil

Si ton problème est en C++:
Ajoute en entête #include <String>

Si c'est en C:
Il faut utiliser les malloc pour les char*.
Si c'est les char[], alors dans ce cas c'est une allocation fixe, et ça devrait marcher si la chaine est courte. ^^

Merci pour ta réponse,
Etrange, concernant l'include String.h je ne trouve rien qui définit le type String, Pièce jointe 179724

J'ai pas mon PC avec mon code en main ce soir, mais imaginons que je dois faire face a malloc()

Code:

---

1 2 3 4 5

char * MonTexte = malloc(10 * sizeof(char)); MonTexte = "Thug life"; printf(" Contenu:%s", Montexte); free(MonTexte); MonTexte = NULL;

---

Ça semble correcte ? :roll:

Encore une fois, tu confonds C et C++.

Le C ne fournit pas un type natif string.

Par contre, le C++ le peut, lui : http://en.cppreference.com/w/cpp/header/string


Donc la question est : Que veux-tu ? Du C ou du C++ ?

Si c'est du C que tu souhaites, ce que tu fais est incorrect.
Pourquoi ? Je t'invite à lire le tuto ici : http://nicolasj.developpez.com/articles/libc/string/

gros attention!

Le C++ définit std::string, pas String avec une majuscule.
Et l'entête à inclure est <string>, pas <string.h> (qu'il convient de remplacer, en C++, par <cstring>)

@archMqx. Oui je sais bien, c'était dans les cas où il s’agit du C++.
@leternel : Effectivement oui, mais ça n'a pas l'aire de fonctionner ou <string> <cstring> : "include/css/4.73/string:43:27: fatal error: bits/cpconfig.h: No such file or directory" c'est surement ma version de gcc qui est trop obsolète.
Donc restons dans l'esprit du C :roll:

Je sus finalement partis sur ça en c (Via la doc gnu gcc) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

char * Allouer_String (const char *Texte) { size_t taille = (size_t)sizeof(Texte); char *value = (char *) malloc (taille + 1); value[taille] = '\0'; return (char *) memcpy (value, Texte, taille); }   int tcp_ping (char *IP, char *icmp)   char * machineIP = Allouer_String(IP); printf(" Machine :%s", machineIP); char * data_icmp= Allouer_String(icmp); printf(" Trame ICMP %s:", data_icmp); printf(" OK!"); return 0; }

---

J'appelle tcp_ping (char *IP, char *icmp) avec comme argument IP = "192.168.1.10" et imcp = "Blabla..."

A la sortie, j'ai seulement :
Machine :192.

Et après crash, plus précisément à "return (char *) memcpy (value, pointeur, taille);"
J'ai aussi l'impression que les allocation s'en foutent si une zone mémoire est déjà alloué, il marge dessus..?

Sois je me suis dégradé, sois je me suis levé du pied gauche ce matin.. Quelqu'un peut me taper les doigts que je comprenne mes erreurs ? :(

Merci

M'est avis qu'un problème, c'est qu'une chaine litéralle n'est pas un char*donc que "192.168.0.1" n'est pas un char* correct.
Toute tentative de modification provoquera une segfault

Code:

---

1 2 3 4 5 6 7 8

int tcp_ping (const char *IP, const char *imcp) char * machineIP = Allouer_String(IP); printf(" Machine :%s", machineIP); char * data_icmp= Allouer_String(imcp); printf(" Trame ICMP %s:", imcp); printf(" OK!"); return 0; }

---

A partir de là, je ne sais pas non plus.

Cela dit, concernant ton gcc, vérifie si tu as la bonne version de la glibc, et si tu n'en as pas plusieurs d'installées.

Arf.. Je n'ai pas d'autres versions, si gcc bug je ne comprend pas comment faire a part une réinstalle qui n'a rien changé. J'ai testé sur une VM histoire de voir si il s'agissait pas d'une RAM défectueuse, mais non..

Laissons mon code, je vais finir par me coincer un doigt entre une touche.. Même si google est mon ami. Je reformule une nouvelle question, qu'on puisse se mettre d'accord sur un bon code :mouarf:

Concrètement Comment créer un char "dynamique", proprement sans débordement ?

Merci

Citation:

---

Envoyé par cpcdos

c'est surement ma version de gcc qui est trop obsolète.

---

non gcc est un compilateur C, pour compiler du C++ il faut utiliser g++

Citation:

---

Code:

---

1 2 3 4

char * Allouer_String (const char *Texte) { size_t taille = (size_t)sizeof(Texte); (...)

---

(...)
A la sortie, j'ai seulement :
Machine :192.

---

Texte est un pointeur, sizeof te donne la taille de ton pointeur, sur une machine 32bits un pointeur prend 4 octets en mémoire, du coup tu positionnes pas ton \0 au bon endroit
pour connaitre la taille d'une chaine de caractères on utilise strlen

mais c'est quoi le but ici ? tu as déjà une chaine Texte en mémoire, tu veux recalculer sa longueur et ré-allouer de la mémoire pour la stocker mais je vois pas bien l’intérêt de le faire en fait, surtout qu'il y a largement la place sur la stack pour stocker une adresse IP et une phrase

sinon dans l'absolu ça peut ressembler à un truc comme ça :

Code:

---

1 2 3 4

int len = strlen(Texte) * sizeof(char); char *toto = malloc(len+1); memset (toto, 0, len+1); // on initialise tout le buffer à zéro, on est assuré que le nul-char terminator est bien là strcpy(Texte, toto);

---

mieux encore, la fonction calloc fait directement l'initialisation à zéro dans la foulée

Code:

---

1 2	char *toto = calloc(strlen(Texte) * sizeof(char) + 1); strcpy(Texte, toto);

---

Citation:

---

Sois je me suis dégradé, sois je me suis levé du pied gauche ce matin.. Quelqu'un peut me taper les doigts que je comprenne mes erreurs ? :(

---

:scarymov::sm:

ps: <blagounette mesquine>pour quelqu'un qui code des kernel t'as du vachement perdre en effet :lol:</blagounette mesquine>

Vicieux ce leternel aujourd'hui :mouarf:

L'erreur est en effet lié sizeof qui renvoie la taille d'un pointeur et non la taille de la chaine jusqu'au \0 terminal. Et c'est bien strlen() + 1 qui donnera la bonne taille à allouer.

Citation:

---

j'ai consulté cette petite documentation qui m'a un peu ouvert l'esprit sur mon problème, qu'apparemment char* et char[] ne devraient exister. C'est par ce qu'ils allouent une zone à la mémoire en mode Yoooooolooooooo ? (sans faire gaffe aux autres variables déjà définies en mémoire?)

---

Cette documentation m'a surtout donné envie de les fermer car tous les accents ont été remplacés par d'atroces symboles empêchant toutes lectures. J'ai vraiment arrêté quand j'ai lu que Java est je ne sais combien de fois plus lent. C'était peut-être vrai en 2000, mais on est en 2015 et la JVM d'Oracle est devenu une brute et le JIT est très puissant. Il parle d'un ratio 3 à 4 avec JIT, peut-être en admettant que tout le monde code bien. La vitesse n'est pas toujours un argument dans le choix d'un langage ou d'une technologie. D'ailleurs, il en vient peu après à poser la question "que choisir en C, C++ et Java ?". Pour gérer des chaines, je prendrais pris Java sans hésiter. OK, je ne connais sans doute pas assez C++ ; mais la classe String en Java est bien fourni et comme on a un GC, on se casse pas la tête avec des free, malloc et autres delete.

Fin de la parenthèse, revenons au C et à char* et char[]. Ils doivent exister, comme il existe int* et int[]. Personne ne pense que ces derniers ne devraient pas exister. Le vrai problème est que c'est la seule solution pour gérer des chaines de caractères. Dire qu'une chaine de caractères est une suite de caractères dont la fin est un simple \0 est le vrai problème car un simple marqueur de fin ne garantit rien sur la taille et toute la charge est sur le développeur pour s'assurer que la taille des données correspond bien à la taille de zone, avec les char comme avec tous les autres types de données. Avec ces derniers, on travaille souvent avec des structures de données mieux définies ou de taille plus fixes. Les chaines de caractères sont par essence de longueur totalement variable, d'où une mise en exergue de la lourdeur à gérer soi-même la mémoire.

Il y a eu 50 tentatives de faire des sur-couches pour gérer mieux les chaines en C et rien de standard n'est sorti. Trois solutions :

• faire son propre système mais ça ne semble être inutile ou alors uniquement pour une application particulière, en plus d'être long à mettre au point et à valider
• se taper la gestion "normale" d'une chaine en C
• utiliser des bibliothèques toutes faites, testées et améliorées avec le temps

Pour des appli ne traitant que peu de chaines, la solution 2 est sans doute la mieux. Pour une appli en traitant beaucoup, je pense pour la 3. La bibliothèque de FranckH est sans doute intéressante.

PS : je regarde un peu plus l'article et il propose sa propre classe String qui copie l'API de la classe String en Java, en proposant StringBuffer qui est aussi une classe Java. Je raconte pas que des conneries en fait ! :aie:.

Je vois des trucs qui piquent un peu dans la suite de code.
- Il dit de bannir char* mais sa classe String possède une méthode pour fournir un char* !
- Ses fonctions alloc() et free() maisons stoppent le programme.
- fprintf(stdout) à gogo.

Bonjour!

Merci pour ta réponse BufferBob, gros fail effectivement au niveau de sizeof VS strlen, je me demandais si ma chaine était pas coupé par autre chose en mémoire mais oui si /0 se place après les 4 octets.. J'ai compris mon erreur!
je vais essayer tout ça d'ici peu :)
J'ai TeamViewvé avec un ami, et on a conclu que la partie C, plus précisément les instanciation des types, des variable, Tableau, écrivent par dessus les autres variables, types descripteurs etc. déjà alloués sur coté FreeBasic.. C'est pour cela que ça crash au retour de tcp_ping() qui ping et renvoi parfaitement mon return 0 ..

@Bktero Merci pour ta réponse, c'est plus clair. Pour la documentation, il faut se mettre en Unicode. :)
J'ai survolé sa fonction, et testé, j'ai que deux erreurs à la compilation, il s'agit de l'argument "..." mais bon j'avais déjà l'idée en tête que ça n'allait pas compiler
Je voudrai bien faire la solution 2, mais il gère très mal la mémoire, du moins les emplacement déjà alloués

Voici deux screenshots qui représente en clair mon problème
Pièce jointe 179897
AdresseIP est déclaré tant que String (dans le crt0 de freebasic) (Pour la photo, le "*" devant AdresseIP ne fait pas partis du code compilé ci-dessous)

Sur VirtualBox :
Pièce jointe 179898

On voit clairement que le contenu "AdresseIP" disparaît après l'appel de TCP_Ping() ! et ce n'est pas le seul et qui donne suite à un crash vu qu'une partie des variables sont erronés.
Mais par-contre, si dans ma fonction TCP_Ping() j’exécute dés la première ligne

Code:

---

1 2 3 4 5 6 7 8 9 10

int cpintiping::tcp_ping (char *machineIP, int taille, char *dataCPC) { return 0;   /* reste du code....   ..   ..   ..   */ }

---

ceci fonctionne

Je n'es pas de segmentations, du moins pas encore, il me semble bien que la couche DPMI est protégé par le ring 0

concrètement, es ce que calloc et malloc test si une zone de mémoire est déjà attribué? :weird:
C'est ça qui m'embête!

<blagounette mesquine reply>Passer du freebasic au C effectivement! ça fais mal :roll:</blagounette mesquine reply>

Citation:

---

Envoyé par cpcdos

Je voudrai bien faire la solution 2, mais il gère très mal la mémoire, du moins les emplacement déjà alloués

---

qui ça "il" ? le C ??

Citation:

---

Code:

---

int cpintiping::tcp_ping (char *machineIP, int taille, char *dataCPC)

---

ceci fonctionne

---

ceci est du C++, j'avais cru comprendre que tu faisais du C, à l'arrivée il semble qu'il y ait aussi du freebasic dans la partie

Citation:

---

Je n'es pas de segmentations, du moins pas encore, il me semble bien que la couche DPMI est protégé par le ring 0

---

ping, chaines de caractères, DPMI, ring0 :koi:

Citation:

---

concrètement, es ce que calloc et malloc test si une zone de mémoire est déjà attribué? :weird:

---

les fonctions {m,c}alloc allouent une zone mémoire dans le tas (heap) et retournent le pointeur sur la zone allouée, à chaque appel c'est une nouvelle zone mémoire qui est allouée, pour libérer la zone on utilise la fonction free, si on ne libère pas la zone on se retrouve avec une fuite mémoire, si on essaye de la libérer deux fois le programme plante pour corruption du heap
l'allocateur heap est géré par le système (...) et vu le nombre d'utilisateurs et d'années qu'il a derrière lui on peut affirmer sans trop se tromper qu'il fait bien le boulot et qu'il (le système, mais ça vaut pour le C aussi) n'est pas en cause

elle correspond à quoi la capture d'écran, un code freebasic ?
vu d'ici on a l'impression que tu essayes d'interfacer 2 langages, écrire une fonction en C que tu utilises dans freebasic, c'est ça ?

Citation:

---

Envoyé par cpcdos

char* et char[] ne devraient exister. C'est par ce qu'ils allouent une zone à la mémoire en mode Yoooooolooooooo ? (sans faire gaffe aux autres variables déjà définies en mémoire?)

---

Citation:

---

Envoyé par cpcdos

concrètement, es ce que calloc et malloc test si une zone de mémoire est déjà attribué? :weird:
C'est ça qui m'embête!

---

8O

Dans quel langage as-tu écris ton kernel ? En FreeBasic ? Pas en C j'espère... Je me demande d'ailleurs ce que ton kernel sait gérer de la mémoire quand je vois tes questions.

Explique-nous l'intérêt d'appeler malloc() ou calloc() si cette fonction réservait une zone au hasard. D'ailleurs, c'est assez antinomique "réserver" et "au hasard". De part la définition même de "réserver", cela veut dire "c'est à moi, merci de ne pas y toucher". Sais-tu ce qu'est un allocateur de mémoire ? C'est le patron dans un grand morceau de mémoire (ici, le tas ou heap en anglais), qui est à lui et à personne d'autre, à qui on peut demander un morceau de cette mémoire (malloc()), qui nous accorde le droit d'utiliser à vie ce bout de mémoire (en renvoyant un pointeur valide) ou pas (en renvoyant NULL), à qui on rend la mémoire quand on n'en a plus besoin (free()) pour ne pas faire de fuite mémoire. C'est en gros le cadastre : il attribue les parcelles dans le tas et chaque parcelle à un unique propriétaire. En revanche, il ne fait pas la police : si tu vas jardiner dans la zone du voisin, il s'en fiche. Ce n'est pas un mécanisme de protection de la mémoire (MMU ou MPU).

Personne à part l'allocateur n'a le droit de réserver de l'espace dans le heap. Quand tu fais char array[1024];, tu réserves dans la pile dans le cas des variables locales et en aucun cas dans le tas. La pile a aussi un gestionnaire. 2 variables sur la pile ne sont jamais au même endroit.

Tu ne pensais quand même pas sérieusement que l'algorithme derrière malloc() ou char[1024] était quelque chose du genre :

Code:

---

1 2 3 4

void * allocate(size_t size) { return (void *) rand(); }

---

:mouarf: ?

Je code mon kernel principalement en FreeBasic, que je nomme "Cpcdos".
La partie C/C++/assembleur, c'est une partie enfin une librairie qui est au plus proche possible du niveau bas que j'appelle "CPinti Core", c'est tout ce qui touche la partie réseau tcp, icmp (où est mon problème), http, ftp (Wattcp32), I/O, routine ISR, le multi-threading (Pthread), multi-core & APIC (tutoriels de Michael Chourdakis en assembleur/c).

Citation:

---

ceci est du C++, j'avais cru comprendre que tu faisais du C, à l'arrivée il semble qu'il y ait aussi du freebasic dans la partie

---

Mais alors GCC est bien un compilateur C++ ? (ou C/C++) :ptdr: par ce que bon, je peux faire des classes, des instances, des méthodes, fonctions privés/publiques/virtuel/static.. C'est pour ça que j'étais brouillé entre le C/C++ au départ :/
le C ne supporte pas ça on est d'accord ?

Citation:

---

ping, chaines de caractères, DPMI, ring0

---

Citation:

---

Je me demande d'ailleurs ce que ton kernel sait gérer de la mémoire quand je vois tes questions.

---

J'ai pas fait de segmentations, j'ai donc pas correctement géré la mémoire, du moins pas encore, je suis entrain de refaire mon projet/prototype à zéro depuis février 2015. L'implémentation du DPMI me donne théoriquement, l'accès à 4go de RAM (Si une carte graphique n'a pas de mémoire dédiée)
la partie applicatif/utilisateur peut accéder à la mémoire kernel (ce qui est forcement déconseillé je sais) pour dire que je n'es pas du tout encore structuré ma mémoire. J'ai cité le "ring0" en parlant du serveur DPMI qui me semble est protégé par ce dernier pour dire que, ma fonction TCP_Ping() ne touche pas cette zone de mémoire. C'était pour mettre hors de cause la méthode que utilise mon kernel.

J'ai simplement structuré la partie c++ avec des classes instanciables, des méthodes&variables privés/publiques, constructeur et destructeur. Et la partie Freebasic avec des tableaux, structs, etc.. Bref un truc bien propre pour la partie programmeur mais apparemment sale pour la RAM :aie:

Citation:

---

elle correspond à quoi la capture d'écran, un code freebasic ?
vu d'ici on a l'impression que tu essayes d'interfacer 2 langages, écrire une fonction en C que tu utilises dans freebasic, c'est ça ?

---

La première capture, oui c'est du FreeBasic. Et oui ce que je fais, c'est que je crée une librairie .a à partir de GCC, que j'ajoute dans le linkage du Freebasic (en le déclarant bien-sûre) ce qui me permet d'utiliser des fonctions codé et compilé en C/C++ à partir du FreeBasic. (ce qui m'a d'ailleurs donné l'idée de refaire mon projet depuis zéro)

L'intérêt d'appeler malloc() ou calloc() est pour la partie C seulement, je pensais pouvoir résoudre mon problème en les utilisant (enfin les re-utilisant du coup :roll:) car je pensais que mes char[] char*, allouait "au hasard" un emplacement mémoire, mais comme vous me le confirmez et mon ami qui confirme explicitement vos propos, je devrai donc remettre en question la partie FreeBasic que je pensais bien gérer.
Et en effet je me suis approfondi dans la documentation du compilateur et utiliser le type "String" qui provient directement du crt0 de Freebasic est "là pour simplifier le développement " avec allocation dynamique et blablabla.. tout pour ne pas décourager le développeur pour au final ne pas utiliser manuellement les fonctions d'allocations mémoire etc... GROSSE FAUTE DE MA PART. :roll:

Pour finir, ce que j'ai essayé, c'est de déclarer ma variable "AdresseIP" cette fois-ci en type "ZString" (cela me rapproche du "style C"), donc je dois allouer une taille en plaçant mon texte "192.168.1.10", l'adresse du pointeur est donc placé dans AdresseIP; j'appelle ma fonction TCP_Ping() il fonctionne bien, jusqu'à là, OK, et j'arrive à afficher ma chaine de caractère en réutilisant ce fameux pointeur! :) ET bizarre comme ça peut l'être, mes quelques autres variables type "String" sont erronés donc mon problème en sorte, partiellement résolu. Du moins, je suppose connaître la cause.

Je dois dire une grosse connerie, mais

• C'est comme si le type "String de FreeBasic" n'avait pas de descripteur, mais une sorte de table propre a freebasic qui stocke les emplacements des adresses utilisées.
• Ou comme si le système d'allocation dynamique d'un string de FreeBasic, c'est d'étendre le reste d'une chaine dans un autre emplacement mémoire en plaçant la prochaine adresse de cette chaine au dernier octet du précédent offset (comme les données d'un fichier qui sont supérieur à la taille d'allocation par défaut d'un disque dur, il va devoir marger le reste des données dans un autre cluster), mais sans descripteur au départ..
• Et un peut comme la exfat/ntfs si on efface la table d'allocation, et bien pour nous c'est un emplacement libre pour le système, mais peut être pas pour un programme qui connait et utilise un offset précise qui apparait non utilisée, mais lisible..

Désolé d'embrouiller les esprits, je pars super loin j'ai dû sortir 70% de bêtises :aie: mais je voulais mettre en lumière, l'aspect du problème de Freebasic que je suppose. Mais bon les développeurs de FreeBasic sont pas aussi bêtes.

Je vais douiller un bon moment pour remplacer tous ces "String" en "ZString" + allouer + mémoriser tous les pointeurs, leçon du codeur, même si on sait utiliser, savoir comment ça marche. La simplicité d'utilisation des routines pré-faites rend les choses plus abstraites à comprendre que la faire sois même, ça va prend un bon moment mais c'est aussi peut être l'occasion de créer cette fameuse segmentation. Redis bonjour à Visual Pradigm :)

Je vous tiens au courant si cette méthode fonctionne pour la totalité du projet, Merci à tous pour vos explication! :-)

Citation:

---

void * allocate(size_t size)
{
return (void *) rand();
}

---

En soit, c'est très bête procéder comme ça, mais si j'avais aucune explications à mon problème, je te jure que j'allais y penser :mouarf:

Techniquement, il y a la GCC (GNU Compiler Collection) contenant g++ (le compilateur C++), gcc (le compilateur générique), cpp (le préprocesseur) et d'autres.

Tu peux voir gcc et g++ comme étant le même programme, sauf que le premier considère par défaut du C, et le second du C++

D'accord, il me semblait bien qu'il y avait un bémol dés le début :)