Passage d'argument NULL !

Bonjour a tous
J'ai un pb de compilation qui me sort des warnings (que je dois supprimer pour le projet) depuis une fonction déclarée comme suit :

Code:

---

extern void msg_trace(char *, char *, long, long, long, long, long) ;

---

Cette fonction est utilisée dans une multitude de sources .c dans le code. Certaines de ces sources passent NULL en argument des 4 ou 5 derniers parametres (alors que la declaration attend un long). Autrement dit, l'appel a cette fonction se fait (par ex) comme :

Code:

---

msg_ano(C_DATE_MACH, C_DATE_MESS_CALC, 130, NULL, NULL, NULL, NULL);

---

Le warning associé a l'une de ces fonctions est du type (et logique):

Code:

---

1 2 3 4

warning: passing argument 4 of ‘msg_ano’ makes integer from pointer without a cast warning: passing argument 5 of ‘msg_ano’ makes integer from pointer without a cast warning: passing argument 6 of ‘msg_ano’ makes integer from pointer without a cast warning: passing argument 7 of ‘msg_ano’ makes integer from pointer without a cast

---

Mon souci, c'est que d'autres fonctions utilisent cette meme fonction msg_ano avec des arguments pouvant etre des long comme attendus.

Quelles solutions s'offrent à moi pour pallier ce pb ?
Le polymorphisme n'existant pas en C, je me vois mal creer autant de fonctions msg_ano_1, msg_ano_2 etc ... que j'ai d'appels possibles avec les differents arguments !

(je ne sais pas si c'est super clair, tout ca)

Dites moi, svp ! :-)
Merci

Tu peux redéfinir NULL autour du code qui appelle ta fonction de cette manière, mais c'est extrêmement sale. « NULL » est défini par <stddef.h> comme un pointeur (en général sur 0).

Par contre, <linux/stddef.h> contient, en tout et pour tout, ceci :

Code:

---

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

#ifndef _LINUX_STDDEF_H #define _LINUX_STDDEF_H       #undef NULL #if defined(__cplusplus) #define NULL 0 #else #define NULL ((void *)0) #endif     #endif

---

Si le C++ définit NULL comme équivalent à « 0 » et qu'il fait le transtypage lui-même, ça expliquerait pourquoi tu te retrouves avec du code qui écrit NULL là où il ne le faut pas. C'est probablement du code C qui a été écrit et compilé dans un environnement C++ (au hasard, Visual Studios).

Merci a toi pour ta reponse

Si je comprends bien, l'environnement de developpement du code source qui utilise la fonction msg_ano aurait interprete les "0" du developpeurs en "NULL" que l'on retrouve dans l'appel a la fonction msg_ano ?!

Je ne sais pas qui a codé ce code et avec quoi.
Ce que je sais, c'est que ce code tourne tres bien sur Unix, Solaris (aucun warning de compilation - peut-etre du a une version de gcc ?! je ne sais pas), mais donne un tas de warning sous linux redhat.

Une question : si je remplace les NULL (intrepretes, donc) par des 0 dans toutes les fonctions appelant msg_ano, cela resoudrait-il mon pb ?
(je n'ai pas bien compris la reponse que tu m'as donné ... je n'ai pas trouvé de stddef.h sous /usr/include du serveur linux)

Merci encore !

Oui, ça résoudrais ton problème, à condition que le zero ne soit pas une valeure possible pour un appel "normal"

Oui, c'est bien pour cela que j'hesite a le faire.
Merci seeme.

Pour en revenir a la definition du NULL, je l'ai trouvé sous :
/usr/include/gdcache.h et /usr/include/pth.h

Est-ce que le code que Obsidian m'a donné pourrait etre directement ecrit dans un define_null.h (par ex) que je creerais pour l'occasion, là où sont toutes mes déclarations .h du projet ? C'est sale ou pas ca ?

Code:

---

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

#ifndef _LINUX_STDDEF_H #define _LINUX_STDDEF_H       #undef NULL #if defined(__cplusplus) #define NULL 0 #else #define NULL ((void *)0) #endif     #endif

---

Merci a vous deux

Je pense que de toute façon, c'est sale... :aie:

En plus c'est le genre de bidouille à hyper bien documenter (comprendre affiche 4 par 3 rouge fluo qui brille dans le noir)... Parce que tu vas te retrouver avec un comportement particulier que tes collègues n'ont peut-être pas prévu...

Etant donné que la surcharge ne fonctionnera pas et si tu veux pas modifier le comportement de tout ceux qui appellent cette fonction, tu pourrais regarder
si tu peux pas passer le prototype de cette fonction en une fonction à nombre de paramètre variable.

Du coup, ça permettrait de l'appeller avec et sans les deux derniers paramètres..

(bon ok, j'avoue, ça t'oblige quand même à retapper dans le code, mais bon, ça peut être une solution..)

Citation:

---

Envoyé par pepito31

Quelles solutions s'offrent à moi pour pallier ce pb ?

---

Ne pas utiliser NULL pour autre chose que des pointeurs, c'est pas concu pour ca comme tu t'en rends compte (pour des raisons historiques ca passe sur certaines implementations et ca casse sur d'autres, mais le choix en C a ete fait clairement, NULL c'est pour les pointeurs et c'est tout).

Hum, biensur, j'ai ete aussi etonné de voir ces NULL alors qu'on attend des types long.
En listant les sources utilisant cette fonction msg_ano, je m'apercois qu'il existe 3 ou 4 grandes familles utilisant soit les 3 premiers arguments (les autres etant positionnés a NULL), soit les 4 premiers, soit les 5 premiers.

La solution que je vois la moins sale est de creer autant de msg_ano (msg_ano_1, msg_ano_2, msg_ano_3) utilisant soit 3, 4 ou 5 arguments et faire appel a ces fonctions là selon qui l'appelle.

L'inconvenient, c'est que cela me fait intervenir dans de nombreuses sources, mais ais-je le choix ?!


Merci en tout cas pour tous vos conseils avisés !!

Citation:

---

Envoyé par pepito31

Si je comprends bien, l'environnement de developpement du code source qui utilise la fonction msg_ano aurait interprete les "0" du developpeurs en "NULL" que l'on retrouve dans l'appel a la fonction msg_ano ?!

---

Je ne pense pas que ce soit du code auto-généré, déduit d'une fonction d'appel, non. Je pense que le programmeur a délibérément utilisé ces marqueurs pour indiquer qu'il n'y avait « pas de valeur » et que le code est passé sans avertissement parce qu'il a été traité par un compilo C++.

Citation:

---

Une question : si je remplace les NULL (intrepretes, donc) par des 0 dans toutes les fonctions appelant msg_ano, cela resoudrait-il mon pb ?

---

Ah, oui, tout-à-fait. Si tu peux le faire, c'est ce qu'il y a de mieux.

Citation:

---

(je n'ai pas bien compris la reponse que tu m'as donné ... je n'ai pas trouvé de stddef.h sous /usr/include du serveur linux)

---

Il est sous /usr/include/linux/stddef.h mais je reconnais que je ne sais pas vraiment pourquoi.

Citation:

---

Envoyé par Obsidian

Il est sous /usr/include/linux/stddef.h mais je reconnais que je ne sais pas vraiment pourquoi.

---

C'est l'entête utilisé pour le kernel, pas celui utilisé pour ton code. Celui-ci se trouve plutot sous /usr/lib/gcc/<version>/include/stddef.h (parce que son code dépend intimement de la version de gcc utilisée).

En C++, NULL doit être défini à une constante entière nulle. Mais g++ utilise __null qui a pour effet de générer des warnings quand le contexte n'est pas celui d'un pointeur.

Merci a vous tous pour vos interventions ! J'y vois plus clair, maintenant.
En en discutant avec le resp. technique, il m'a signalé que nous laisserons les warning dus a ces problemes de cast sur NULL et que si le client souhaite les enlever, on leur proposera 2 solutions :

- Remplacer les NULL par des '0' (on y revient!)
- utiliser la fonction msg_ano avec un nombre d'arguments variables (qui n'est pas une norme de codage du client)

Voila, je crois que le sujet est clos et validé :ccool:
Merci

À ton service, mais n'oublie pas :resolu:. Merci.