warning: function returns address of local variable
65 réponses
pere.noel
à la compile d'un ensemble de fonctions + main, j'ai le message de
warning :
function returns address of local variable
pour la fonction "target_path_normalize"
elle retourne ce path normalisé :
target_path_normalized = /Users/yvon/work/.headers toto/CFArray.h
cette fonction "marche" mais je me demande quel risque je prends en
laissant trainer ce warning
le contexte : avant l'utilisation de cette fonction, j'en utilise une
autre "target_path_check" qui retourne NULL si le path n'est pas absolu
et accessoirement supprime le "/" en fin de chaîne s'il existe.
--- target_path_normalize ---------------------------------------------
char* target_path_normalize(const char* target_path)
{
int trente_deux = 32; /* maximum de répertoires traversés */
int mille_vingt_quatre = 1024; /* taille maximum d'un path */
char p[mille_vingt_quatre]="";
char *q;
char *token;
const char needle[] = "/";
const char *dot = ".";
const char *dotdot = "..";
int j;
q = strdup(target_path);
j = 0;
char *pieces[trente_deux];
// initialisation des éléments du tableau à NULL
while(j < trente_deux) {
pieces[j] = NULL;
j++;
}
// démarrage du découpage de q (target_path)
token = strtok(q, needle);
j = 0;
// découpage de q (target_path)
while(token != NULL) {
// si ".." on décrémente j equivalent à cd ..
// si "." on ne fait rien
// si différent de ".." et de "." on enregistre token dans
pieces[j] et on incrémente j
if(strcmp(token, dotdot) == 0) {
j--;
} else if(strcmp(token, dot) != 0) {
pieces[j]=token;
j++;
}
token = strtok(NULL, needle);
}
j = 0;
// concaténation de "/" (needle) et de pieces[j] jusqu'à épuisement
(quand pieces[j] == NULL)
while(pieces[j] != NULL) {
strcat(p, needle);
strcat(p, pieces[j]);
j++;
}
return p;
}
-----------------------------------------------------------------------
donc c'est le "return p" qui pose pb à la compil mais pas à
l'utilisation.
--
une bévue
-----^---- le @ là c'est pour générer une doc, je suppose ?
Oui, j'utilise la syntaxe doxygen pour mes commentaires.
ok, ça ressemble à javadoc...
-- une bévue
Eric Levenez
Le 8/09/06 8:22, dans <45010c40$0$27210$, « Harpo » a écrit :
Eric Levenez wrote:
*(q--) = 0; est plus lisible.
Les parenthèses ne servent ici qu'à surcharger inutilement la lecture,
Je ne me rappelle jamais de la précédence des opérateurs.
C'est pourtant la base : le ++ et le -- placés après un nom incrémente et décrémente la variable __après__ utilisation. C'est le but de ces opérateurs.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 8/09/06 8:22, dans <45010c40$0$27210$636a55ce@news.free.fr>, « Harpo »
<invalid@invalid.invalid> a écrit :
Eric Levenez wrote:
*(q--) = 0;
est plus lisible.
Les parenthèses ne servent ici qu'à surcharger inutilement la lecture,
Je ne me rappelle jamais de la précédence des opérateurs.
C'est pourtant la base : le ++ et le -- placés après un nom incrémente et
décrémente la variable __après__ utilisation. C'est le but de ces
opérateurs.
Le 8/09/06 8:22, dans <45010c40$0$27210$, « Harpo » a écrit :
Eric Levenez wrote:
*(q--) = 0; est plus lisible.
Les parenthèses ne servent ici qu'à surcharger inutilement la lecture,
Je ne me rappelle jamais de la précédence des opérateurs.
C'est pourtant la base : le ++ et le -- placés après un nom incrémente et décrémente la variable __après__ utilisation. C'est le but de ces opérateurs.
Je trouve au contraire que c'est une bonne habitude de systématiser: p = malloc(nbrObjets * sizeof(type));
Je ne partage pas cet avis. Ce que je trouve utile, c'est p = malloc(nbrObjets * sizeof(*p)); // ou p[0]...
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
Pierre Maurette
[...]
p = (char *) malloc (PATH_SIZE_MAX * sizeof (char));
Je crois que sizeof(char) vaut toujours 1, à vérifier.
Oui. Il a eu droit à la remarque une demi-douzaine de fois, et je n'ai pas tout lu ;-) Je trouve au contraire que c'est une bonne habitude de systématiser: p = malloc(nbrObjets * sizeof(type));
En revanche, ED étant en vacance(*), il n'a eu droit à rien (dans ce que j'ai lu) sur le cast superflu. L'argument (capillotracté) contre est qu'il masque un warning éventuel. L'argument (fallacieux) pour est qu'il compile en C++, où le malloc() est "fonctiona non grata". La bonne pratique un peu veule est de le virer avant de poster ici.
(*) j'ignore s'il est en vacances.
-- Pierre Maurette
[...]
p = (char *) malloc (PATH_SIZE_MAX * sizeof (char));
Je crois que sizeof(char) vaut toujours 1, à vérifier.
Oui. Il a eu droit à la remarque une demi-douzaine de fois, et je n'ai
pas tout lu ;-)
Je trouve au contraire que c'est une bonne habitude de systématiser:
p = malloc(nbrObjets * sizeof(type));
En revanche, ED étant en vacance(*), il n'a eu droit à rien (dans ce
que j'ai lu) sur le cast superflu. L'argument (capillotracté) contre
est qu'il masque un warning éventuel. L'argument (fallacieux) pour est
qu'il compile en C++, où le malloc() est "fonctiona non grata". La
bonne pratique un peu veule est de le virer avant de poster ici.
p = (char *) malloc (PATH_SIZE_MAX * sizeof (char));
Je crois que sizeof(char) vaut toujours 1, à vérifier.
Oui. Il a eu droit à la remarque une demi-douzaine de fois, et je n'ai pas tout lu ;-) Je trouve au contraire que c'est une bonne habitude de systématiser: p = malloc(nbrObjets * sizeof(type));
En revanche, ED étant en vacance(*), il n'a eu droit à rien (dans ce que j'ai lu) sur le cast superflu. L'argument (capillotracté) contre est qu'il masque un warning éventuel. L'argument (fallacieux) pour est qu'il compile en C++, où le malloc() est "fonctiona non grata". La bonne pratique un peu veule est de le virer avant de poster ici.
(*) j'ignore s'il est en vacances.
-- Pierre Maurette
Pierre Maurette
Le 08-09-2006, Pierre Maurette a écrit :
Je trouve au contraire que c'est une bonne habitude de systématiser: p = malloc(nbrObjets * sizeof(type));
Je ne partage pas cet avis. Ce que je trouve utile, c'est p = malloc(nbrObjets * sizeof(*p)); // ou p[0]...
C'est mieux.
-- Pierre Maurette
Le 08-09-2006, Pierre Maurette <maurettepierre@wanadoo.fr> a écrit :
Je trouve au contraire que c'est une bonne habitude de systématiser:
p = malloc(nbrObjets * sizeof(type));
Je ne partage pas cet avis. Ce que je trouve utile, c'est
p = malloc(nbrObjets * sizeof(*p)); // ou p[0]...
Je trouve au contraire que c'est une bonne habitude de systématiser: p = malloc(nbrObjets * sizeof(type));
Je ne partage pas cet avis. Ce que je trouve utile, c'est p = malloc(nbrObjets * sizeof(*p)); // ou p[0]...
C'est mieux.
-- Pierre Maurette
Harpo
Eric Levenez wrote:
Le 8/09/06 8:22, dans <45010c40$0$27210$, « Harpo » a écrit :
Eric Levenez wrote:
*(q--) = 0; est plus lisible.
Les parenthèses ne servent ici qu'à surcharger inutilement la lecture,
Je ne me rappelle jamais de la précédence des opérateurs.
C'est pourtant la base : le ++ et le -- placés après un nom incrémente et décrémente la variable __après__ utilisation. C'est le but de ces opérateurs.
C'est une chose différente, là vous parlez de la sémantique; non de la syntaxe. Si on ne connais pas la précédence de * et -- on peut se demander si *p-- veut dire *(p--) ou (*p)--, dans les 2 cas il s'agit d'une post-décrémentation.
On peut trouver de bonne raisons pour, par exemple changer return(0) par blah(0) (bjah = macro) de manière simple sans avoir à faire des expressions régulières compliquées pour changer un ensemble de sources.
-- http://patrick.davalan.free.fr/
Eric Levenez wrote:
Le 8/09/06 8:22, dans <45010c40$0$27210$636a55ce@news.free.fr>, «
Harpo » <invalid@invalid.invalid> a écrit :
Eric Levenez wrote:
*(q--) = 0;
est plus lisible.
Les parenthèses ne servent ici qu'à surcharger inutilement la
lecture,
Je ne me rappelle jamais de la précédence des opérateurs.
C'est pourtant la base : le ++ et le -- placés après un nom incrémente
et décrémente la variable __après__ utilisation. C'est le but de ces
opérateurs.
C'est une chose différente, là vous parlez de la sémantique; non de la
syntaxe.
Si on ne connais pas la précédence de * et -- on peut se demander si
*p-- veut dire *(p--) ou (*p)--, dans les 2 cas il s'agit d'une
post-décrémentation.
On peut trouver de bonne raisons pour, par exemple changer return(0) par
blah(0) (bjah = macro) de manière simple sans avoir à faire des
expressions régulières compliquées pour changer un ensemble de sources.
Le 8/09/06 8:22, dans <45010c40$0$27210$, « Harpo » a écrit :
Eric Levenez wrote:
*(q--) = 0; est plus lisible.
Les parenthèses ne servent ici qu'à surcharger inutilement la lecture,
Je ne me rappelle jamais de la précédence des opérateurs.
C'est pourtant la base : le ++ et le -- placés après un nom incrémente et décrémente la variable __après__ utilisation. C'est le but de ces opérateurs.
C'est une chose différente, là vous parlez de la sémantique; non de la syntaxe. Si on ne connais pas la précédence de * et -- on peut se demander si *p-- veut dire *(p--) ou (*p)--, dans les 2 cas il s'agit d'une post-décrémentation.
On peut trouver de bonne raisons pour, par exemple changer return(0) par blah(0) (bjah = macro) de manière simple sans avoir à faire des expressions régulières compliquées pour changer un ensemble de sources.
