j'ai une question sur realloc:
$ cat testrealloc.c
#include <stdio.h>
#include <stdlib.h>
int main(void){
char * c=NULL;
c=malloc(8);
if (c == NULL) return -1;
c="abcdefgh";
printf("valeur du pointeur: %d\r\n",c);
printf("valeur de c: %s\r\n",c);
c=realloc(c,16);
return 0;
}
$ gcc -Wall -o testrealloc testrealloc.c
testrealloc.c: In function 'main':
testrealloc.c:9: attention : format '%d' expects type 'int', but argument 2
has type 'char *'
$ ./testrealloc
valeur du pointeur: 134514000
valeur de c: abcdefgh
Erreur de segmentation
Ma question est: pourquoi le realloc segfaulte?
Merci
--
Kevin
Oui. J'ai perdu du temps avec ce bordel. s est un /char étoile/ non modifiable.
Pour être précis et chipoter encore, un pointeur sur un/des char non modifiables.
Ainsi "s[0] = ' ';" peut, selon l'architecture, provoquer un crash (SEGV)
[ Pour remporter le prix du chipotage, on peut aussi écrire: static const char*const s = "coucou";
Car de toute manière, sans le static, on assigne une variable temporairement à un pointeur qui est de toute manière statique.
Tout ce bazard ne changera rien après compilation, mais bon, voila. ]
Pascal J. Bourguignon
Pierre Maurette writes:
Lucas Levrel, le 5/7/2011 a écrit :
[...]
char *s="coucou";
Et pourquoi ce ne serait pas mieux d'écrire:
char* s = "coucou";
Pour un être humain normalement consititué, et sain d'esprit, c'est certain que:
char* s="coucou";
est mieu: cela reflète plus précisément ce que nous avons en tête.
Mais pour un barbu américain travaillant dans une boite de téléphone dans les années 70, qui s'est fait jeté du projet multics, et qui à tout juste le droit d'utiliser un pdp-7 parce que personne n'en veut parce que c'est une machine tellement ridicule déjà à l'époque qu'on ne peut pratiquement rien faire de serrieux avec, et d'ailleur ce barbu la seule chose qui l'intéresse s'est de faire tourner son petit jeu de "Space Travel", et bien pour ce barbu, char* s="coucou", c'est mieux, parce que déjà ce paragraphe ferait un dépassement de mémoire sur son PDP-7, alors ça lui permet de parser les déclarations de variable pointeur avec la même grammaire que les déréférencement, ce qui doit bien lui faire gagner 3,7 mots machines.
Donc, depuis lors, les compilateur C parsent:
char * s = "coucou" | / | / . | / | / |/ . / /
et non:
char * s = "coucou" / | / / |/ . / /
Par conséquent, ça peut être utile d'écrire:
char *s="coucou";
parce que c'est comme ça que le compilateur va le comprendre, et ça permet d'éviter des erreurs du genre:
char* s="coucou",c,d; strcpy(c,s);
(ce qui dans les premiers C compilait parfaitement, et écrasait une zone mémoire quelconque (en adresses bases de préférence, dont importantes) avec "coucou". De nos jours les compilateurs vont donner un "warning").
Personnelement, j'écrirais une variable par déclaration:
char* s="coucou"; char* c; char* d;
ainsi le problème ne se pose pas. Mais le mieux encore une fois, c'est de ne pas utiliser ces satanés char*, mais:
-- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.
Pierre Maurette <maurette.pierre@free.fr> writes:
Lucas Levrel, le 5/7/2011 a écrit :
[...]
char *s="coucou";
Et pourquoi ce ne serait pas mieux d'écrire:
char* s = "coucou";
Pour un être humain normalement consititué, et sain d'esprit, c'est
certain que:
char* s="coucou";
est mieu: cela reflète plus précisément ce que nous avons en tête.
Mais pour un barbu américain travaillant dans une boite de téléphone
dans les années 70, qui s'est fait jeté du projet multics, et qui à tout
juste le droit d'utiliser un pdp-7 parce que personne n'en veut parce
que c'est une machine tellement ridicule déjà à l'époque qu'on ne peut
pratiquement rien faire de serrieux avec, et d'ailleur ce barbu la seule
chose qui l'intéresse s'est de faire tourner son petit jeu de "Space
Travel", et bien pour ce barbu, char* s="coucou", c'est mieux, parce que
déjà ce paragraphe ferait un dépassement de mémoire sur son PDP-7, alors
ça lui permet de parser les déclarations de variable pointeur avec la même
grammaire que les déréférencement, ce qui doit bien lui faire gagner 3,7
mots machines.
Donc, depuis lors, les compilateur C parsent:
char * s = "coucou"
| / | /
. | /
| /
|/
.
/
/
et non:
char * s = "coucou"
/ | /
/ |/
.
/
/
Par conséquent, ça peut être utile d'écrire:
char *s="coucou";
parce que c'est comme ça que le compilateur va le comprendre, et ça
permet d'éviter des erreurs du genre:
char* s="coucou",c,d;
strcpy(c,s);
(ce qui dans les premiers C compilait parfaitement, et écrasait une zone
mémoire quelconque (en adresses bases de préférence, dont importantes)
avec "coucou". De nos jours les compilateurs vont donner un "warning").
Personnelement, j'écrirais une variable par déclaration:
char* s="coucou";
char* c;
char* d;
ainsi le problème ne se pose pas. Mais le mieux encore une fois, c'est
de ne pas utiliser ces satanés char*, mais:
Pour un être humain normalement consititué, et sain d'esprit, c'est certain que:
char* s="coucou";
est mieu: cela reflète plus précisément ce que nous avons en tête.
Mais pour un barbu américain travaillant dans une boite de téléphone dans les années 70, qui s'est fait jeté du projet multics, et qui à tout juste le droit d'utiliser un pdp-7 parce que personne n'en veut parce que c'est une machine tellement ridicule déjà à l'époque qu'on ne peut pratiquement rien faire de serrieux avec, et d'ailleur ce barbu la seule chose qui l'intéresse s'est de faire tourner son petit jeu de "Space Travel", et bien pour ce barbu, char* s="coucou", c'est mieux, parce que déjà ce paragraphe ferait un dépassement de mémoire sur son PDP-7, alors ça lui permet de parser les déclarations de variable pointeur avec la même grammaire que les déréférencement, ce qui doit bien lui faire gagner 3,7 mots machines.
Donc, depuis lors, les compilateur C parsent:
char * s = "coucou" | / | / . | / | / |/ . / /
et non:
char * s = "coucou" / | / / |/ . / /
Par conséquent, ça peut être utile d'écrire:
char *s="coucou";
parce que c'est comme ça que le compilateur va le comprendre, et ça permet d'éviter des erreurs du genre:
char* s="coucou",c,d; strcpy(c,s);
(ce qui dans les premiers C compilait parfaitement, et écrasait une zone mémoire quelconque (en adresses bases de préférence, dont importantes) avec "coucou". De nos jours les compilateurs vont donner un "warning").
Personnelement, j'écrirais une variable par déclaration:
char* s="coucou"; char* c; char* d;
ainsi le problème ne se pose pas. Mais le mieux encore une fois, c'est de ne pas utiliser ces satanés char*, mais:
Le littéral chaîne n'existe que pendant les instants de la compilation.
Si il n'est plus là au run, à quoi sert le const char * ?
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
Lucas Levrel
Le 7 mai 2011, Pierre Maurette a écrit :
const char* s = "coucou";
Oui. J'ai perdu du temps avec ce bordel. s est un /char étoile/ non modifiable. En fait un pointeur sur une chaîne en dur. Un littéral chaîne. Le littéral chaîne n'existe que pendant les instants de la compilation.
Peux-tu expliciter ? La chaîne en question est encore dans l'exécutable.
-- LL
Le 7 mai 2011, Pierre Maurette a écrit :
const char* s = "coucou";
Oui. J'ai perdu du temps avec ce bordel. s est un /char étoile/ non
modifiable. En fait un pointeur sur une chaîne en dur. Un littéral chaîne.
Le littéral chaîne n'existe que pendant les instants de la compilation.
Peux-tu expliciter ? La chaîne en question est encore dans l'exécutable.
Oui. J'ai perdu du temps avec ce bordel. s est un /char étoile/ non modifiable. En fait un pointeur sur une chaîne en dur. Un littéral chaîne. Le littéral chaîne n'existe que pendant les instants de la compilation.
Peux-tu expliciter ? La chaîne en question est encore dans l'exécutable.
-- LL
Xavier Roche
Le 07/05/2011 21:57, Lucas Levrel a écrit :
Le 7 mai 2011, Xavier Roche a écrit :
[ Pour remporter le prix du chipotage, on peut aussi écrire: static const char*const s = "coucou";
Quand on écrit (const) char *s="coucou"; s n'est pas const.
Oui, là je supposais que s n'avait pas de raison d'être modifié (étant statique)
Le 07/05/2011 21:57, Lucas Levrel a écrit :
Le 7 mai 2011, Xavier Roche a écrit :
[ Pour remporter le prix du chipotage, on peut aussi écrire:
static const char*const s = "coucou";
Quand on écrit
(const) char *s="coucou";
s n'est pas const.
Oui, là je supposais que s n'avait pas de raison d'être modifié (étant
statique)
[ Pour remporter le prix du chipotage, on peut aussi écrire: static const char*const s = "coucou";
Quand on écrit (const) char *s="coucou"; s n'est pas const.
Oui, là je supposais que s n'avait pas de raison d'être modifié (étant statique)
Pierre Maurette
Lucas Levrel, le 5/7/2011 a écrit :
Le 7 mai 2011, Pierre Maurette a écrit :
const char* s = "coucou";
Oui. J'ai perdu du temps avec ce bordel. s est un /char étoile/ non modifiable. En fait un pointeur sur une chaîne en dur. Un littéral chaîne. Le littéral chaîne n'existe que pendant les instants de la compilation.
Peux-tu expliciter ? La chaîne en question est encore dans l'exécutable.
Si je compile:
int i = 0;
quel est le statut et la valeur de &i lors de la compilation ?
La réponse: une valeur numérique immédiate.
-- Pierre Maurette
Lucas Levrel, le 5/7/2011 a écrit :
Le 7 mai 2011, Pierre Maurette a écrit :
const char* s = "coucou";
Oui. J'ai perdu du temps avec ce bordel. s est un /char étoile/ non
modifiable. En fait un pointeur sur une chaîne en dur. Un littéral chaîne.
Le littéral chaîne n'existe que pendant les instants de la compilation.
Peux-tu expliciter ? La chaîne en question est encore dans l'exécutable.
Si je compile:
int i = 0;
quel est le statut et la valeur de &i lors de la compilation ?
Oui. J'ai perdu du temps avec ce bordel. s est un /char étoile/ non modifiable. En fait un pointeur sur une chaîne en dur. Un littéral chaîne. Le littéral chaîne n'existe que pendant les instants de la compilation.
Peux-tu expliciter ? La chaîne en question est encore dans l'exécutable.
Si je compile:
int i = 0;
quel est le statut et la valeur de &i lors de la compilation ?
La réponse: une valeur numérique immédiate.
-- Pierre Maurette
Pascal J. Bourguignon
Lucas Levrel writes:
Le 7 mai 2011, Pierre Maurette a écrit :
const char* s = "coucou";
Oui. J'ai perdu du temps avec ce bordel. s est un /char étoile/ non modifiable. En fait un pointeur sur une chaîne en dur. Un littéral chaîne. Le littéral chaîne n'existe que pendant les instants de la compilation.
Peux-tu expliciter ? La chaîne en question est encore dans l'exécutable.
Quand tu tape DEL dans ton éditeur, que deviennent les caractères supprimés? Ils partent au paradis des octets?
-- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.
Lucas Levrel <lucas.levrel@u-pec.fr> writes:
Le 7 mai 2011, Pierre Maurette a écrit :
const char* s = "coucou";
Oui. J'ai perdu du temps avec ce bordel. s est un /char étoile/ non
modifiable. En fait un pointeur sur une chaîne en dur. Un littéral
chaîne.
Le littéral chaîne n'existe que pendant les instants de la compilation.
Peux-tu expliciter ? La chaîne en question est encore dans l'exécutable.
Quand tu tape DEL dans ton éditeur, que deviennent les caractères
supprimés? Ils partent au paradis des octets?
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
Oui. J'ai perdu du temps avec ce bordel. s est un /char étoile/ non modifiable. En fait un pointeur sur une chaîne en dur. Un littéral chaîne. Le littéral chaîne n'existe que pendant les instants de la compilation.
Peux-tu expliciter ? La chaîne en question est encore dans l'exécutable.
Quand tu tape DEL dans ton éditeur, que deviennent les caractères supprimés? Ils partent au paradis des octets?
-- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.
Pascal J. Bourguignon
(Marc Espie) writes:
In article , Pierre Maurette wrote:
Lucas Levrel, le 5/7/2011 a écrit :
[...]
char *s="coucou";
Et pourquoi ce ne serait pas mieux d'écrire:
char* s = "coucou";
Parce qu'on est dans fr.comp.lang.c, pas fr.comp.lang.c++
Ce n'est pas la bonne raison, car c'est pareil en C++.
-- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.
espie@lain.home (Marc Espie) writes:
In article <mn.3cc17db5be9fc028.79899@free.fr>,
Pierre Maurette <maurette.pierre@free.fr> wrote:
Lucas Levrel, le 5/7/2011 a écrit :
[...]
char *s="coucou";
Et pourquoi ce ne serait pas mieux d'écrire:
char* s = "coucou";
Parce qu'on est dans fr.comp.lang.c, pas fr.comp.lang.c++
Ce n'est pas la bonne raison, car c'est pareil en C++.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.