variables globales et plusieurs fichiers.h et .c

Version imprimable

Voir 40 message(s) de cette discussion en une page

Perdu:

Code:

1
2
	puts("----==== Tests sans MFC ====----");
	char toto[] = "TOTO\0";	printf("%Iu : ", strlen(toto)); puts(toto);

Code:

1
2
----==== Tests sans MFC ====----
4 : TOTO

02/03/2007, 17h14
stephl
Citation:
Envoyé par souviron34

si tu déclares une variable :

Code:

1 2 char toto[] = "TOTO"

et que tu fasses printf ou strlen() tu trouveras 4 et TOTO..

Si tu lui mets "TOTO\0" tu trouveras 6 et TOTO\0
Je suis sûr du contraire et je viens de le tester avec un petit programme compilé sous Borland. C'est le premier '\0' qui marque la fin d'une chaîne; dans votre exemple, la valeur retournée par strlen() est toujours 4.

Plus intéressant par contre:

Code:

1
2
    { char toto[] = "TOTO\0"; printf("%Iu - %d : ", strlen(toto), (int)sizeof(toto)); puts(toto); }
    { char tata[] = "TATA";   printf("%Iu - %d : ", strlen(tata), (int)sizeof(tata)); puts(tata); }

Code:

1
2
4 - 6 : TOTO
4 - 5 : TATA

Citation:

Envoyé par souviron34

FAUX .. Fais un printf ( chaine) ....

Et pour l'autre post pareil.....

As-tu suivi ton conseil?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
~/src 7> cat souviron34.c
#include <stdio.h>
 
char souviron1[] = "souviron";
char souviron2[] = "souviron\0";
char const* souviron3 = "souviron";
char const* souviron4 = "souviron\0";
 
int main()
{
    printf("|%s|\n|%s|\n|%s|\n|%s|\n", souviron1, souviron2, souviron3, souviron4);
    return 0;
}
 
~/src 8> cc -o souviron34 souviron34.c
~/src 9> ./souviron34
|souviron|
|souviron|
|souviron|
|souviron|

Citation:

Envoyé par Médinoc

Plus intéressant par contre:

Code:

1
2
    { char toto[] = "TOTO\0"; printf("%Iu - %d : ", strlen(toto), (int)sizeof(toto)); puts(toto); }
    { char tata[] = "TATA";   printf("%Iu - %d : ", strlen(tata), (int)sizeof(tata)); puts(tata); }

Code:

1
2
4 - 6 : TOTO
4 - 5 : TATA

Ca paraît logique! :)

02/03/2007, 17h25
Médinoc

En effet.
Et ça montre bien que toto contient deux \0 au lieu d'un.
02/03/2007, 17h44
souviron34

peut-être que les compilateurs ont évolués... En tous cas je sais que sur HPUX il y a 10 ans, ça marchait pas... dépassement de mémoire... Je ne sais pas si c'est une évolution globale ou une particularité de ce qui est dispo sous Windows. J'avoue que ce monde m'est étranger.

Pour le print j'ai réfléchi et c'est pafaitement normal (come le sprintf ouf fprintf) : il interprète. Par contre le strlen() ou strcpy, ça ne marchait pas... On verra. Pas le temps aujourdhui mais je testerais sur mon linux..

Mais de toutes façons quel est l'intérêt ???????

puisque "TOTO" a automatiquemnt le '/0' à la fin... ??

Citation:

Envoyé par souviron34

si tu déclares une variable :

Code:

1
2
 
char toto[] = "TOTO"

et que tu fasses printf ou strlen() tu trouveras 4 et TOTO..

Si tu lui mets "TOTO\0" tu trouveras 6 et TOTO\0

Non. C'est l'heure de la sieste, non ?

Tu confonds strlen() et sizeof...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
#include <stdio.h>
#include <string.h>
 
int main (void)
{
   char a[] = "abc";
   char b[] = "abc\0";
   char c[] = "abc\0\0";
 
#define PRT(s)\
   printf (#s"='%s' len=%u size=%u\n"\
          , s\
          , (unsigned) strlen(s)\
          , (unsigned) sizeof s)
 
   PRT(a);
   PRT(b);
   PRT(c);
 
#undef PRT
 
   return 0;
}

Code:

1
2
3
4
5
6
 
a='abc' len=3 size=4
b='abc' len=3 size=5
c='abc' len=3 size=6
 
Press ENTER to continue.

02/03/2007, 17h57
Emmanuel Delahaye

Citation:

Envoyé par souviron34

Mais de toutes façons quel est l'intérêt ???????

Le traitement de certains résultats sous la forme

Code:

"info\0info\0info\0"

est nécessaire avec certaines fonctions de l'API Windows. Le C le permet.

Je reconnais que c'est tordu et que les fonctions standards du C ne sont pas utilisables ici. Mais ça n'a jamais gêné Microsoft...
02/03/2007, 17h57
Jean-Marc.Bourguet

Citation:

Envoyé par souviron34

peut-être que les compilateurs ont évolués...

C'est specifie comme ca dans la norme de 89 et ca m'a l'air de remonter au moins a B (en 1972, voir http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html mais en B le caractere d'echappement, c'est * pas \)

Citation:

En tous cas je sais que sur HPUX il y a 10 ans, ça marchait pas... dépassement de mémoire...

Tu me permettras de douter et de penser que tu confonds avec autre chose.

Citation:

Je ne sais pas si c'est une évolution globale ou une particularité de ce qui est dispo sous Windows. J'avoue que ce monde m'est étranger.

A moi aussi. J'ai les meme resultats avec Sun cc, gcc sous Linux et acc sous AIX.

Citation:

Mais de toutes façons quel est l'intérêt ???????

puisque "TOTO" a automatiquemnt le '/0' à la fin... ??

Il est vraissemblable que l'OP a agit par ignorance.
02/03/2007, 18h15
souviron34
Citation:

Envoyé par Jean-Marc.Bourguet

Tu me permettras de douter et de penser que tu confonds avec autre chose.
.

peut-être.. Mais je me souviens que c'était un (très bon) programmeur du service pour lequel je bossais qui avait mis des initialisations comme ça (dans une adaptaton de la biblothèque HTTP 1.0), que ça plantait, et que dès qu'on enlevait ces /0 dans les chaînes ça marchait....

Bon.. Pas grave...

Mais avec ce que dit Emmanuel
Citation:
Le traitement de certains résultats sous la forme

Code:

1 2 "info\0info\0info\0"est nécessaire avec certaines fonctions de l'API Windows. Le C le permet.

Je reconnais que c'est tordu et que les fonctions standards du C ne sont pas utilisables ici. Mais ça n'a jamais gêné Microsoft...
ça me semble plus explicable :mur: :arf:

pôvres de nous ....
02/03/2007, 19h49
gl

Citation:

Envoyé par souviron34

et que dès qu'on enlevait ces /0 dans les chaînes ça marchait....

/0 ou \0 ? Car \0 est bel et bien un seul caractere mais /0 ce sont deux caracteres
02/03/2007, 21h57
James_

Pour revenir à mon sujet car il me semble qu'il a un peu dérivé, en sachant que ça dépend du compilateur de transcrire "\0" en un seul caractère ou non (norme ANSI)...

Citation:

Le principal problème de ton code est qu'il est horriblement mal organisé...

Il y a des principes de nommage, de découpage et de sectionnage du code à respecter, même si ils ne sont issus que de la pratique et du bon sens.

Je te conseille de lire ceci.

http://emmanuel-delahaye.developpez.com/codage.htm

Voici comment je réorganiserais ton code en fonction de ces critères.

Je suis d'accord avec toi mais le hic c'est que j'ai vu aucun bouquin qui explique concrètement comment faire pour organiser correctement un programme "conséquent" et évolutif avec au minimum une vingtaine de fichiers.h et .c.

Sinon, je ne sais plus comment faire pour imprimer une discution ici, avant il existait un bouton "imprimez" non?
Je n'ai pas trop le choix de découper autant
03/03/2007, 11h43
Jean-Marc.Bourguet

Citation:

Envoyé par souviron34

peut-être.. Mais je me souviens que c'était un (très bon) programmeur du service pour lequel je bossais qui avait mis des initialisations comme ça (dans une adaptaton de la biblothèque HTTP 1.0), que ça plantait, et que dès qu'on enlevait ces /0 dans les chaînes ça marchait....

Si on utilise sizeof dans ce genre de contexte, on peut se trouver à envoyer un \0 (je suppose que c'est une typo) de trop ou pas assez.

Citation:

ça me semble plus explicable :mur: :arf:

pôvres de nous ....

J'ai pas une sympathie folle pour MS, mais à mon avis ils n'ont fait qu'utiliser quelque chose qui existait déjà. Si j'y pense, je testerai surun vieil Unix pour PDP-11.
03/03/2007, 12h18
Jean-Marc.Bourguet

Citation:

Envoyé par James_

Pour revenir à mon sujet car il me semble qu'il a un peu dérivé, en sachant que ça dépend du compilateur de transcrire "\0" en un seul caractère ou non (norme ANSI)...

Ca ne dépend pas. Un littéral chaine de caractères est stocké avec un \0 final supplémentaire, même si il y en a déjà un.
03/03/2007, 12h22
Emmanuel Delahaye

Citation:

Envoyé par James_

Je suis d'accord avec toi mais le hic c'est que j'ai vu aucun bouquin qui explique concrètement comment faire pour organiser correctement un programme "conséquent" et évolutif avec au minimum une vingtaine de fichiers.h et .c.

D'où l'utilité de mon petit article. Tu sauras le refaire maintenant ?
03/03/2007, 13h35
James_

Citation:

Envoyé par Jean-Marc.Bourguet

Ca ne dépend pas. Un littéral chaine de caractères est stocké avec un \0 final supplémentaire, même si il y en a déjà un.

Je ne suis pas d'accord. J'utilise un compilateur Palm OS vers 9.xx pour un système indépendant et embarqué et il n'ajoute pas un \0 après un \0 sauf si on utilise par exemple une variable de type un tableau de caractères de taille fixe dans ce cas il remplacera tous les octets suivant par un \0.

Citation:

Envoyé par Emmanuel Delahaye

D'où l'utilité de mon petit article. Tu sauras le refaire maintenant ?

Après avoir étudié ton article et avoir insérer les emplacements dans mes fichiers.h et .c, je me rends compte que j'utilisé la même méthode avec les "#define" rassemblés au même endroit, pareil pour les prototypes, les variables etc... juste l'ordre de mes emplacements étaient différents. Et celà ne change rien, j'ai toujours ce BUG.
Alors finalement ma question tourne sur: dans quel fichier.c faut-il définir des variables globales ou des structures lorsqu'on en a plusieurs. Pourquoi le fait de couper-coller dans différents fichiers.c certaines définitions de variables influence l'execution d'un programme?
03/03/2007, 14h34
Emmanuel Delahaye

Citation:

Envoyé par James_

Je ne suis pas d'accord. J'utilise un compilateur Palm OS vers 9.xx pour un système indépendant et embarqué et il n'ajoute pas un \0 après un \0 sauf si on utilise par exemple une variable de type un tableau de caractères de taille fixe dans ce cas il remplacera tous les octets suivant par un \0.

Tu veux dire qu'avec ce compilateur

Code:

char *s="hello";

et

Code:

char s[] = "hello";

ne forment pas des chaines valides ? Tu peux le prouver ? Tu as une doc qui le spécifie ? Si c'est c'est le cas, ce n'est pas un compilateur C conforme et il ne permet pas d'écrire ni ne réutiliser du code portable. C'est très embêtant....

Citation:

Après avoir étudié ton article et avoir insérer les emplacements dans mes fichiers.h et .c, je me rends compte que j'utilisé la même méthode avec les "#define" rassemblés au même endroit, pareil pour les prototypes, les variables etc... juste l'ordre de mes emplacements étaient différents. Et celà ne change rien, j'ai toujours ce BUG.

Heu, j'ai posté un code qui n'avait ce bug, il ne te convient pas ?

Citation:

Alors finalement ma question tourne sur: dans quel fichier.c faut-il définir des variables globales ou des structures lorsqu'on en a plusieurs. Pourquoi le fait de couper-coller dans différents fichiers.c certaines définitions de variables influence l'execution d'un programme?

Tout le principe est décrit dans mon article et illustré par l'exemple que j'ai posté. Tu suis les règles et ça fonctionne. Que dire de plus ?

Je donne des cours particuliers (Paris)...
03/03/2007, 17h53
Jean-Marc.Bourguet
Citation:

Envoyé par James_

Je ne suis pas d'accord. J'utilise un compilateur Palm OS vers 9.xx pour un système indépendant et embarqué et il n'ajoute pas un \0 après un \0 sauf si on utilise par exemple une variable de type un tableau de caractères de taille fixe dans ce cas il remplacera tous les octets suivant par un \0.

Si exécuter le programme
Code:

1 2 3 4 5 6 7 8 9 #include <stdio.h> char foo[] = "foo\0"; int main() { printf("The size of foo is %d.\n", (int)sizeof foo); return 0; }
n'affiche pas

The size of foo is 5.

Le compilateur n'est pas conforme. Si tu n'es pas d'accord, il va te falloir argumenter autrement. Et comme je l'ai déjà montré, c'est quelque chose qui remonte au moins à B.
03/03/2007, 23h13
Jean-Marc.Bourguet
Citation:
Envoyé par Jean-Marc.Bourguet

Si exécuter le programme

Code:

1 2 3 4 5 6 7 8 9 #include <stdio.h> char foo[] = "foo\0"; int main() { printf("The size of foo is %d.\n", (int)sizeof foo); return 0; }

n'affiche pas

The size of foo is 5.

Le compilateur n'est pas conforme. Si tu n'es pas d'accord, il va te falloir argumenter autrement. Et comme je l'ai déjà montré, c'est quelque chose qui remonte au moins à B.
Je me suis un peu amusé. Exécuter un programme semblable (sans la ligne include) compilé avec le compilateur C de Unix 7th edition (1979) donne bien 5 comme taille de foo.

Voir 40 message(s) de cette discussion en une page