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
Les parenthèses ne servent ici qu'à surcharger inutilement la lecture,
Je ne me rappelle jamais de la précédence des opérateurs.
Idem. Je préfère *(q--), *(q--), --(*q) et (*q)-- au doute.
un peu comme les :
return(0);
que l'on voit trop souvent :-)
Ca donne un style macro.
Autant que des pompes vernies bicolores ?
-- Pierre Maurette
Harpo
Pierre Maurette wrote:
En revanche, ED étant en vacance(*),
J'espère.
il n'a eu droit à rien (dans ce que j'ai lu) sur le cast superflu.
Si, par 2 fois.
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.
Je vais écrire un scanner destiné à présenter les sources pour qu'ils puissent être présenté su fclc. Je propose que ce forum soit modéré par un robot qui scannera automatiquement les posts et qui corrigera les erreurs usuelles.
-- http://patrick.davalan.free.fr/
Pierre Maurette wrote:
En revanche, ED étant en vacance(*),
J'espère.
il n'a eu droit à rien (dans ce
que j'ai lu) sur le cast superflu.
Si, par 2 fois.
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.
Je vais écrire un scanner destiné à présenter les sources pour qu'ils
puissent être présenté su fclc.
Je propose que ce forum soit modéré par un robot qui scannera
automatiquement les posts et qui corrigera les erreurs usuelles.
il n'a eu droit à rien (dans ce que j'ai lu) sur le cast superflu.
Si, par 2 fois.
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.
Je vais écrire un scanner destiné à présenter les sources pour qu'ils puissent être présenté su fclc. Je propose que ce forum soit modéré par un robot qui scannera automatiquement les posts et qui corrigera les erreurs usuelles.
-- http://patrick.davalan.free.fr/
Eric Levenez
Le 8/09/06 13:10, dans <EccMg.149$, « Stéphane Goujet » a écrit :
Rien à voir : le problème de Harpo est de savoir quelle est la variable concernée, q ou *q.
C'est las base quand même. Que l'on ne connaisse pas toutes les précédences des opérateurs, c'est normal. Mais là quand même.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 8/09/06 13:10, dans <EccMg.149$hD2.4@read3.inet.fi>, « Stéphane Goujet »
<stephane.goujet@pp.invalid> a écrit :
Rien à voir : le problème de Harpo est de savoir quelle est la
variable concernée, q ou *q.
C'est las base quand même. Que l'on ne connaisse pas toutes les précédences
des opérateurs, c'est normal. Mais là quand même.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 8/09/06 13:59, dans , « Pierre Maurette » a écrit :
Idem. Je préfère *(q--), *(q--), --(*q) et (*q)-- au doute.
Et je suppose que tu fais aussi :
n = (2) * (3);
:-)
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Marc Boyer
Le 08-09-2006, Eric Levenez a écrit :
Le 8/09/06 13:29, dans , « Marc Boyer » a écrit :
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]...
p = malloc(nbrObjets * sizeof *p);
sizeof n'est pas une fonction, tout comme return, et on ne met pas de parenthèses, sauf si c'est un type et pas une variable.
J'avoue ma grande flemme: je n'arrive pas à me motiver pour apprendre cette règle là, et donc, je mets systématiquement les parenthèses... Honte à moi.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
Le 08-09-2006, Eric Levenez <news@levenez.com> a écrit :
Le 8/09/06 13:29, dans <slrneg2ld6.nfk.Marc.Boyer@localhost.localdomain>,
« Marc Boyer » <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit :
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]...
p = malloc(nbrObjets * sizeof *p);
sizeof n'est pas une fonction, tout comme return, et on ne met pas de
parenthèses, sauf si c'est un type et pas une variable.
J'avoue ma grande flemme: je n'arrive pas à me motiver
pour apprendre cette règle là, et donc, je mets systématiquement
les parenthèses...
Honte à moi.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. Paul Éluard)
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]...
p = malloc(nbrObjets * sizeof *p);
sizeof n'est pas une fonction, tout comme return, et on ne met pas de parenthèses, sauf si c'est un type et pas une variable.
J'avoue ma grande flemme: je n'arrive pas à me motiver pour apprendre cette règle là, et donc, je mets systématiquement les parenthèses... Honte à moi.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
pere.noel
Eric Levenez wrote:
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.
ça peut poser problème aux personnes qui écrivent de droite à gauche... (suivant la langue pratiqué) -- une bévue
Eric Levenez <news@levenez.com> wrote:
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.
ça peut poser problème aux personnes qui écrivent de droite à gauche...
(suivant la langue pratiqué)
--
une bévue
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.
ça peut poser problème aux personnes qui écrivent de droite à gauche... (suivant la langue pratiqué) -- une bévue
Eric Levenez
Le 8/09/06 16:48, dans , « Marc Boyer » a écrit :
Le 08-09-2006, Eric Levenez a écrit :
p = malloc(nbrObjets * sizeof *p);
sizeof n'est pas une fonction, tout comme return, et on ne met pas de parenthèses, sauf si c'est un type et pas une variable.
J'avoue ma grande flemme: je n'arrive pas à me motiver pour apprendre cette règle là, et donc, je mets systématiquement les parenthèses...
C'est comme pour un cast d'une variable en un type donné : on met des parenthèses autour du type.
int i;
sizeof(int) sizeof i;
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 8/09/06 16:48, dans <slrneg311j.8gp.Marc.Boyer@localhost.localdomain>,
« Marc Boyer » <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit :
Le 08-09-2006, Eric Levenez <news@levenez.com> a écrit :
p = malloc(nbrObjets * sizeof *p);
sizeof n'est pas une fonction, tout comme return, et on ne met pas de
parenthèses, sauf si c'est un type et pas une variable.
J'avoue ma grande flemme: je n'arrive pas à me motiver
pour apprendre cette règle là, et donc, je mets systématiquement
les parenthèses...
C'est comme pour un cast d'une variable en un type donné : on met des
parenthèses autour du type.
int i;
sizeof(int)
sizeof i;
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
sizeof n'est pas une fonction, tout comme return, et on ne met pas de parenthèses, sauf si c'est un type et pas une variable.
J'avoue ma grande flemme: je n'arrive pas à me motiver pour apprendre cette règle là, et donc, je mets systématiquement les parenthèses...
C'est comme pour un cast d'une variable en un type donné : on met des parenthèses autour du type.
int i;
sizeof(int) sizeof i;
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Eric Levenez
Le 8/09/06 17:18, dans <1hlcvjm.13t6x8q103v73gN%, « Une bévue » a écrit :
Eric Levenez wrote:
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.
ça peut poser problème aux personnes qui écrivent de droite à gauche...
On peut toujours trouver des excuses, mais ce ne sont que des excuses.
Quand tu fais :
a = b;
Penses-tu que beaucoup de programmeurs C pensent que dans ce cas on va mettre a dans b ? Enfin j'espère pas. Et puis là les parenthèses ce n'est pas jouable...
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 8/09/06 17:18, dans
<1hlcvjm.13t6x8q103v73gN%pere.noel@laponie.com.invalid>, « Une bévue »
<pere.noel@laponie.com.invalid> a écrit :
Eric Levenez <news@levenez.com> wrote:
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.
ça peut poser problème aux personnes qui écrivent de droite à gauche...
On peut toujours trouver des excuses, mais ce ne sont que des excuses.
Quand tu fais :
a = b;
Penses-tu que beaucoup de programmeurs C pensent que dans ce cas on va
mettre a dans b ? Enfin j'espère pas. Et puis là les parenthèses ce n'est
pas jouable...
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 8/09/06 17:18, dans <1hlcvjm.13t6x8q103v73gN%, « Une bévue » a écrit :
Eric Levenez wrote:
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.
ça peut poser problème aux personnes qui écrivent de droite à gauche...
On peut toujours trouver des excuses, mais ce ne sont que des excuses.
Quand tu fais :
a = b;
Penses-tu que beaucoup de programmeurs C pensent que dans ce cas on va mettre a dans b ? Enfin j'espère pas. Et puis là les parenthèses ce n'est pas jouable...
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
