Discussion :

[pepito31]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Obsidian]

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 C :

Sélectionner tout - Visualiser dans une fenêtre à part

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).

[pepito31]

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 !

[seeme]

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

[pepito31]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[seeme]

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

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..)

[Jean-Marc.Bourguet]

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).

[pepito31]

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 !!

[Obsidian]

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++.

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.

(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.

[Jean-Marc.Bourguet]

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.

[pepito31]

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é
Merci

[Obsidian]

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