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
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é)
La précédence des opérateurs ne suit justement pas directement l'évaluation dans un sens. par exemple : 1 + 2 * 3 ce qui, sauf dans un langage délibérément casse-couille, se lit : 1 + (2 * 3) et non (1 + 2) * 3
En notation polonaise, c'est plus simple mais il y a des programmeurs qui n'aiment pas ce gene de langage, pour cette raison je préfère mettre des parenthèses dès qu'il peut y avoir un doute dans la tête de celui qui lit comme dans la mienne.
-- http://patrick.davalan.free.fr/
Une bévue wrote:
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é)
La précédence des opérateurs ne suit justement pas directement
l'évaluation dans un sens.
par exemple :
1 + 2 * 3
ce qui, sauf dans un langage délibérément casse-couille, se lit :
1 + (2 * 3)
et non
(1 + 2) * 3
En notation polonaise, c'est plus simple mais il y a des programmeurs
qui n'aiment pas ce gene de langage, pour cette raison je préfère
mettre des parenthèses dès qu'il peut y avoir un doute dans la tête de
celui qui lit comme dans la mienne.
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é)
La précédence des opérateurs ne suit justement pas directement l'évaluation dans un sens. par exemple : 1 + 2 * 3 ce qui, sauf dans un langage délibérément casse-couille, se lit : 1 + (2 * 3) et non (1 + 2) * 3
En notation polonaise, c'est plus simple mais il y a des programmeurs qui n'aiment pas ce gene de langage, pour cette raison je préfère mettre des parenthèses dès qu'il peut y avoir un doute dans la tête de celui qui lit comme dans la mienne.
-- http://patrick.davalan.free.fr/
pere.noel
Eric Levenez wrote:
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...
non pour le pb des parenthèse, par contre pour le pb : gauche -> droite c'est autre chose...
à Bornéo j'ai connu des ingés japonais qui avaient beaucoup de mal avec notre écritue, ils étaient quasiment obligés de doubler la première année.
je n'ai pas ce pb, mais ça ne me semble pas aussi évident que ça à s'y mettre, j'en voudrais pour preuve que ldans es bandes dessinées le héros de balade aussi de droite à gauche, quand c'est l'inverse on a l'impression qu'il rvient. cinéma, pareil. -- une bévue
Eric Levenez <news@levenez.com> wrote:
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...
non pour le pb des parenthèse, par contre pour le pb : gauche -> droite
c'est autre chose...
à Bornéo j'ai connu des ingés japonais qui avaient beaucoup de mal avec
notre écritue, ils étaient quasiment obligés de doubler la première
année.
je n'ai pas ce pb, mais ça ne me semble pas aussi évident que ça à s'y
mettre, j'en voudrais pour preuve que ldans es bandes dessinées le héros
de balade aussi de droite à gauche, quand c'est l'inverse on a
l'impression qu'il rvient. cinéma, pareil.
--
une bévue
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...
non pour le pb des parenthèse, par contre pour le pb : gauche -> droite c'est autre chose...
à Bornéo j'ai connu des ingés japonais qui avaient beaucoup de mal avec notre écritue, ils étaient quasiment obligés de doubler la première année.
je n'ai pas ce pb, mais ça ne me semble pas aussi évident que ça à s'y mettre, j'en voudrais pour preuve que ldans es bandes dessinées le héros de balade aussi de droite à gauche, quand c'est l'inverse on a l'impression qu'il rvient. cinéma, pareil. -- une bévue
pere.noel
Harpo wrote:
En notation polonaise, c'est plus simple mais il y a des programmeurs qui n'aiment pas ce gene de langage, pour cette raison je préfère mettre des parenthèses dès qu'il peut y avoir un doute dans la tête de celui qui lit comme dans la mienne.
oui, je ne parlais pas des précédences.
le gros truc je crois c'est qu'en info l'opérateur = est disymétrique contrairement à sa graphie (pascal écrivant := sans doute pour cette raison).
rien n'empécherait un compilo de lire de gauche à droite non ? :
*basename=(char *)tmp+1;
;1+pmt(* char)=emanesab*
c'est nettement + lisible non ? ;-) -- une bévue
Harpo <invalid@invalid.invalid> wrote:
En notation polonaise, c'est plus simple mais il y a des programmeurs
qui n'aiment pas ce gene de langage, pour cette raison je préfère
mettre des parenthèses dès qu'il peut y avoir un doute dans la tête de
celui qui lit comme dans la mienne.
oui, je ne parlais pas des précédences.
le gros truc je crois c'est qu'en info l'opérateur = est disymétrique
contrairement à sa graphie (pascal écrivant := sans doute pour cette
raison).
rien n'empécherait un compilo de lire de gauche à droite non ? :
En notation polonaise, c'est plus simple mais il y a des programmeurs qui n'aiment pas ce gene de langage, pour cette raison je préfère mettre des parenthèses dès qu'il peut y avoir un doute dans la tête de celui qui lit comme dans la mienne.
oui, je ne parlais pas des précédences.
le gros truc je crois c'est qu'en info l'opérateur = est disymétrique contrairement à sa graphie (pascal écrivant := sans doute pour cette raison).
rien n'empécherait un compilo de lire de gauche à droite non ? :
*basename=(char *)tmp+1;
;1+pmt(* char)=emanesab*
c'est nettement + lisible non ? ;-) -- une bévue
Jean-Marc Bourguet
Harpo writes:
Une bévue wrote:
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é)
La précédence des opérateurs ne suit justement pas directement l'évaluation dans un sens. par exemple : 1 + 2 * 3 ce qui, sauf dans un langage délibérément casse-couille, se lit : 1 + (2 * 3) et non (1 + 2) * 3
1+2*3 vaut 7 2*3+1 vaut 8
en APL (tous les opérateurs ont la même priorité et s'évaluent de droite à gauche).
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Harpo <invalid@invalid.invalid> writes:
Une bévue wrote:
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é)
La précédence des opérateurs ne suit justement pas directement
l'évaluation dans un sens.
par exemple :
1 + 2 * 3
ce qui, sauf dans un langage délibérément casse-couille, se lit :
1 + (2 * 3)
et non
(1 + 2) * 3
1+2*3 vaut 7
2*3+1 vaut 8
en APL (tous les opérateurs ont la même priorité et
s'évaluent de droite à gauche).
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
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é)
La précédence des opérateurs ne suit justement pas directement l'évaluation dans un sens. par exemple : 1 + 2 * 3 ce qui, sauf dans un langage délibérément casse-couille, se lit : 1 + (2 * 3) et non (1 + 2) * 3
1+2*3 vaut 7 2*3+1 vaut 8
en APL (tous les opérateurs ont la même priorité et s'évaluent de droite à gauche).
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Harpo
Jean-Marc Bourguet wrote:
1+2*3 vaut 7 2*3+1 vaut 8
" One and one is two Six and two is eight Come on baby don't ya make me late Hey... babe don't you wanna go Come on babe don't you wanna go Back to that same old place, Sweet home Chicago. "
-- http://patrick.davalan.free.fr/
Jean-Marc Bourguet wrote:
1+2*3 vaut 7
2*3+1 vaut 8
" One and one is two
Six and two is eight
Come on baby don't ya make me late
Hey... babe don't you wanna go
Come on babe don't you wanna go
Back to that same old place,
Sweet home Chicago. "
" One and one is two Six and two is eight Come on baby don't ya make me late Hey... babe don't you wanna go Come on babe don't you wanna go Back to that same old place, Sweet home Chicago. "