Copier un char* dans un char*? pas resolu-C'est pour ce soir:/ [C/C++] - C++ - Programmation
Marsh Posté le 30-10-2002 à 09:07:06
J'ai un peu de mal à te suivre ...
Tu utilises un union pour ... convertir un type ?
Dans ce cas, un simple cast suffit !
Code :
|
Pour interpréter un tableau de char comme uns struct packet (le char * que tu recois) tu fais ((packet *)data)->packetID ...
Les fonctions strXXX s'utilisent sur des string terminée par '\0'.
Toi tu manipules des tableaux.
Rien à voir. Utilises une fonction telle que memcpy pour copier des buffer -> buffer, mais d'apres ce que j'ai compris, de simple cast suffisent dans ton cas (= forcer le type)
Marsh Posté le 30-10-2002 à 12:59:33
pareil: toutes les fonctions qui commencent par mem : elles sont ultra-preforamntes et sures (faut quand meme savoir ce qu'on fait)
ou si tu es sous Un*x regarde dans ton API, il y a plein d'extensions tres bien
Marsh Posté le 30-10-2002 à 15:06:07
HelloWorld a écrit a écrit : J'ai un peu de mal à te suivre ... Tu utilises un union pour ... convertir un type ? Dans ce cas, un simple cast suffit !
|
Notre librairie doit marcher avec un programme ftp qu'ils nous ont file...
Moi aussi au debut je me demandais ct quoi l'interet de l'union, mais regarde plutot ca :
Code :
|
Ca doit marcher avec ca...
Et le mec fait des unions
Je mate memcpy mais je sens que cela ne va pas regler mon probleme ( vu que memcpy ne connait pas le nb d'octets a lire )
Marsh Posté le 30-10-2002 à 15:18:44
Citation : |
Ben justement, memcpy prend en paramètre le nb d'octets.
tu le connais, donc ça roule !!!
Marsh Posté le 30-10-2002 à 15:21:31
pascal_ a écrit a écrit :
|
Je ne le connais pasm le voila le souci !
Ma fonction recoit un char* a la base...
et si tu regardes ses specifs :
- Ne se termine pas par '\0' ( mate l'union... )
- On a pas le nb d'octets en parametres (sic)
- Je dois faire fonctionner ma librairie avec le programme ftp, qui lui m'envoie direct le tableau tire de l'union
Donc non, je ne connais pas le nombre d'octets pointe par le pointeur char* data en parametre de mysend ...
Et c'est la qu'est mon souci :|
Marsh Posté le 30-10-2002 à 17:04:56
Bon bah comme il veut pas se faire chier le prof (voila sa reponse) :
-Oh, I didn't ran into that problem... What I'm doing is to copy the array and whatever is next, and that works
-well, it depends on what you have next... if it's still the program data in the memory, it will work, if you run into the OS memory... Segmentation fault. It depends on how the compiler will allocate your memory and how much you will be using.
-Right... So I don't know. Maybe you should do the union with a array of character that is already the biggest size ever possible in the application.
-OK, but that's not a good programming right ? The user will have to stick to that size and know how long the biggest packet is...
-Yes, but for now on, only focus on if it works or not. If it's ugly programming, don't care about it.
- ... ok, bye.
Le vieux debile...
Enfin bref.
Marsh Posté le 30-10-2002 à 17:06:34
Citation :
|
ni du C, ni du C++.
sinon std ca te dit quelque chose? le substantypage des fonctions de la bibliothèque C? les (f)stream? les string?
je veux pas t'engueuler mais ton code c'est le plus gros rammassi de merde de mélange C/C++ que j'ai jamais vu. C'est du Windows? j'm'en serais douter.
Mais bordel, C et C++ sont deux langages différents!
Marsh Posté le 30-10-2002 à 17:33:29
Taz@PPC a écrit a écrit :
|
Bon ben je te file l'email du prof quand tu veux.
C'est pas mon programme ca... relis le truc. c'est le programme de test pour verifier que notre librairie + notre process de transport marche.
Et en l'occurence, c'est du linux ( ca a ete fait sous solaris exactement).
Donc bon, ta mauvaise heumeur, tes reflexions debiles et autres, tu peux te les garder pour toi hein...
Quand bien meme cela aurait ete mon code a moi, il y a des facons plus aimables de le dire.
Le paragraphe sur windows denote aussi une tendance adolescente assez prononcee.
Tolerance power.
A bon entendeur...
Marsh Posté le 30-10-2002 à 17:36:28
Taz@PPC a écrit a écrit : reviens quand tu sauras ce que sont le C et le C++. |
Je connais la difference, merci.
Je fais que suivre ses specifs et utiliser le prog qu'il NOUS A fourni, vu qu'il le testera avec ca.
Putain, t'es vraiment borne.
Si avec mon planetairum en OpenGL je connais pas le C++...
Si avec mes quelques annes de C je le connais pas...
Je suis pas un expert mais je me demerde. Stoo.
Le programme que tu incendies en ce moment par pur egocentrisme et par pure volonte de flamber n'est pas le mien
Marsh Posté le 30-10-2002 à 17:41:49
Taz@PPC a écrit a écrit : je suis vénère par ce que j'ai le meme problème: un prof qu'il faudrait pendre par le testicule droit (oui le droit) tellement qu'il est nulle. daisolai |
Pas de souci mais essaye d'etre moins aggressif la prochaine fois
Je trouve ce projet interessant sur le fond, mais les specifs que l'on doit suivre sont tellement IDIOTES ( je souligne ) que le projet deviens debile.
C'est con, enfin, le prof est comme ca...
Notez qu'il a change les specifs 4 fois, a chaque fois en nous filant un delai supplementaire... le projet devant durer initialement 2 semaines, bah a dure 1 mois...
Cherchez l'erreur...
Enfin moi j'execute... je fais son programme a la con car ca m'entraine a la prog reseau...
Rien ne m'empechera de programmer plus propre plus tard
Marsh Posté le 30-10-2002 à 17:44:47
Tetedeiench a écrit a écrit : Pas de souci mais essaye d'etre moins aggressif la prochaine fois |
j'ai toujours eu cette réputation.
mwa aussi je fais un projet C++ et le code du prof est buggé et dangereux, pas portable, pas performant au possible et n'est en fait que du C.
et pi moi d'ailleurs, je dis pas spécif', mais spec'
Marsh Posté le 30-10-2002 à 17:52:24
Citation : |
Ca serait pas plutôt un problème d'algorithmique ?
Le nombre d'octects reçu ou envoyé un send ou recv doit
être connu. C'est obligatoire (enfin selon moi).
Marsh Posté le 30-10-2002 à 18:37:54
pascal_ a écrit a écrit :
|
Ouai, mais il veut pas changer les specs une 5eme ou 6eme fois
Marsh Posté le 30-10-2002 à 18:59:31
Entre tes explications et le prog de ton prof, je suis un peu perdun mais je vais te dire ce que j'ai compris :
Code :
|
il a fait l'union pour pouvoir convertir le header en char *.
Tu connais la taille la taille totale d'un packet. Partant de là, considère le union comme un cast.
Toi tu ne fournis que des primitives d'envoi : d'apres ce source, le buffer attendu doit faire 1026 caracteres.
Donc tes primitives acceptent un char * et considèrent que ce char * fait 1026 caractères.
Apres si le prof se demmerde mal avec tes primitives et qu'il paume la taille du fichier en cours d'envois et que donc il créé à l'arrivée un fichier trop gros (il rajoute des octets nuls en plus) ben c'est pas ton probleme. Tu ne peux pas créer une librairie qui corrige les bugs du programme qui l'utilise.
Donc tes fonctions envoi et receptions envoient 1026 caracteres.
De toute façon le '\0' n'est pas une bonne idée car ce '\0' peut être contenu dans le fichier envoyé ...
Pose ces questions à ton prof :
à quoi sert la variable size ? (faudrait l'envoyer ...)
- pourquoi un union et pas un cast ?
- pourquoi un fwrite de 1024 octets : le fichier qui sort sera un multiplee de 1024 (donc test ce programme avec un fichier ayant cette caracteristique et ca marchera !)
- vous pigez ce que vous écrivez ?
- comment le faites vous marcher ?
- vous avez passé combien de temps sur ce prog ?
- vous programmez depuis combien de temps ?
- vous êtes prof d'info depuis combien de temps ?
Pour bien faire, faudrait que ta lib accepte en paramètre le nombre d'octets à envoyer. Sinon elle est à chier car elle impose de travailler avec une taille donnée.
Marsh Posté le 30-10-2002 à 20:49:55
HelloWorld a écrit a écrit : Entre tes explications et le prog de ton prof, je suis un peu perdun mais je vais te dire ce que j'ai compris :
|
La bonne reponse est la derniere phrase...
Le fwrite bah... je pense pas qu'il y aie pense...
C'est un debile ce gars
Marsh Posté le 31-10-2002 à 02:54:49
Tetedeiench et Taz se rencontrent... BOUM !
Mais ils ont faits pour s'entendre.
Marsh Posté le 31-10-2002 à 05:21:59
Taz@PPC a écrit a écrit : pareil: toutes les fonctions qui commencent par mem : elles sont ultra-preforamntes et sures (faut quand meme savoir ce qu'on fait) |
oui il faut tout de meme savoir ce qu'on fait
a savoir lire la doc:
memcpy ne peut pas etre utilise sur deux blocs qui se recouvrent partiellement (ou a tes risques et perils)
memmove lui peut-etre utilise dans tous les cas (mais il fait une copie supplementaire).
A+
LeGreg
Marsh Posté le 31-10-2002 à 05:27:22
Code :
|
y a-t-il une relation entre maxbuflen et 1026 ?
LeGreg
Marsh Posté le 31-10-2002 à 06:36:20
legreg : non, c'est juste la taille maximale du paquet que tu peux recevoir...
En l'occurence, MAXBUFLEN vaut 2000 ici...
Si tu vois le souci, je suis preneur ( data et packet ne se recouvrent en aucun cas )
Marsh Posté le 31-10-2002 à 07:18:56
hum, tu prends un paquet sur le reseau qui peut faire jusqu'a 2000 octets, tu le mets dans une structure qui fait au mieux 1150 octets et tu ne vois pas de souci?
LeGreg
Marsh Posté le 31-10-2002 à 15:21:50
legreg a écrit a écrit : hum, tu prends un paquet sur le reseau qui peut faire jusqu'a 2000 octets, tu le mets dans une structure qui fait au mieux 1150 octets et tu ne vois pas de souci? LeGreg |
Greg, le packet, a la base, c'est moi qui l'envoie.
J'ai mis le buffer a 2000 pour etre tranquille pour les tests, mais a la base j'envoie une structure composee de 2 int, de 2 char[50] et de 1 char[1026], ce dernier que je veux copier dans le char[1026] passe en aprametre...
En fait, j'envoie la structure en haut du receiver.
C'est pas un peu logique d'ailleurs quand tu recois une structure que d'envoyer une structure identique afin de pouvoir bosser avec ?
Enfin ca resoud pas mon probleme : il se trouve damns le memcpy.
Si j'affiche le char[1026] de la struct no soucy... y a bien des caractreres dedans, et ceux qui me faut.
Si je veux copier le char[1026] de ma structure dans mon parametre, des la copie du premier caractere ( teste avec un for) => segmentation fault.
Le vla mon souci
Marsh Posté le 31-10-2002 à 16:42:15
pliz je comprends pas
Marsh Posté le 31-10-2002 à 16:51:06
tout en haut, premier post.
Je le remets ici :
j'apelle cette fois la fonction myRecv :
Code :
|
Fonction myRecv que voici, dans une autre librairie :
Code :
|
Je fais rien de bien mechant : je prends un packet sur le reseau, le mets dans la struct, et je veux copier un champ de mon packet dans le aprametre data pour que l'utilisateur fasse mumuse avec...
Et a chaque fois que je lance ca j'ai une segmentation fault...
Le segmentation fault est sur le memcpy... ou debut que je copie un truc dans la zone memoire pointee par le parametre data
Marsh Posté le 31-10-2002 à 17:10:15
ca donne quoi strlen(datpack.data2) ?
et tu es sur que data est assez grand ?
Marsh Posté le 31-10-2002 à 17:16:55
charlene a écrit a écrit : ca donne quoi strlen(datpack.data2) ? et tu es sur que data est assez grand ? |
strlen ne marche pas car ce n'est pas une chaine de caracteres... Y a pas de \0 a la fin.
Ouip, j'en suis sur ( si tu regardes le codes essai est un tableau de 1026 caracteres et data2 aussi), et de plus, ca merde a la PREMIERE copie.
Style meme :
data[0] = datpack2[0];
fait un segmentation fault :'(
Marsh Posté le 31-10-2002 à 17:21:39
Tetedeiench a écrit a écrit : strlen ne marche pas car ce n'est pas une chaine de caracteres... Y a pas de \0 a la fin. Ouip, j'en suis sur ( si tu regardes le codes essai est un tableau de 1026 caracteres et data2 aussi), et de plus, ca merde a la PREMIERE copie. Style meme : data[0] = datpack2[0]; fait un segmentation fault :'( |
ben, voila une bonne info !
et c'est
data[0] = 'a';
ou l'acces a datpak.data2[0] qui pose problème ?
Marsh Posté le 31-10-2002 à 17:35:14
je peux acceder sans souci au contenu de datpack.data2 ...
si je l'imprime caractere par caractere aucun souci, et le contenu est conforme a ce que j'en attends.
Donc c'est l'acces a data[0] qui fait planter le systeme...
J'ai essaye *(data) mais spareil.
Marsh Posté le 31-10-2002 à 17:47:25
Tetedeiench a écrit a écrit : je peux acceder sans souci au contenu de datpack.data2 ... si je l'imprime caractere par caractere aucun souci, et le contenu est conforme a ce que j'en attends. Donc c'est l'acces a data[0] qui fait planter le systeme... J'ai essaye *(data) mais spareil. |
Bon et bien voila où est le probleme, suit au debugger ce sur quoi pointe data (et essai)
que se passe-t-il dans "..."
entre la déclaration de essai et son utilisation ?
Es-tu sure de bien passer la variable que tu déclares, ne serait-elle pas masquée par une autre ?
Marsh Posté le 31-10-2002 à 17:52:58
BENB a écrit a écrit : Bon et bien voila où est le probleme, suit au debugger ce sur quoi pointe data (et essai) que se passe-t-il dans "..." entre la déclaration de essai et son utilisation ? Es-tu sure de bien passer la variable que tu déclares, ne serait-elle pas masquée par une autre ? |
Certain, j'ai essaye plusieurs variables.
Si tu veux le source code ( bordellique car pleins de tests successifs ) :
Code :
|
Ca c la librairie ( oui je sais elle est crade faut que je la nettoie).
Pareil, le programme de test est crade :
Code :
|
Le debuggueur, faut que je me souvienne comment on s'en sert, surtout que debugguer une librairie je sais pas faire...
Mais bon, je fais que passer un pointeur, c ca que je comprends pas
Marsh Posté le 31-10-2002 à 17:58:13
legreg a écrit a écrit : oui il faut tout de meme savoir ce qu'on fait a savoir lire la doc: memcpy ne peut pas etre utilise sur deux blocs qui se recouvrent partiellement (ou a tes risques et perils) memmove lui peut-etre utilise dans tous les cas (mais il fait une copie supplementaire). A+ LeGreg |
Je ne vois pas pourquoi memmove devrait faire une copie supplémentaire ? Je dis ça d'après une vielle implémentation de memmove que j'avais fait il y a bien longtemps et je suis sur de m'en être tiré en une seule copie
Marsh Posté le 31-10-2002 à 18:04:17
...
Il est pas si mal ton code...
Si tu veux j'en ai ici personne ne sait en quel langue sont les commentaires... mais c'est pas tres grave... il n'y en pas bcp
Effectivment sa parait bon... il sagirait alors d'un effet de bord, et sans un purify ou un debugger c'est difficile...
tu es sous linux, tu n'as pas ddd ?
debugger une lib c'est comme un executable, mais il faut un executable de test... ca tombe bien tu l'as
au pire fait des printf a plusieurs niveaux, dans le main y compris...
surveilles bien ce qui se passe lors de l'appel de la fonction...
Marsh Posté le 31-10-2002 à 18:16:40
BENB a écrit a écrit : ... Il est pas si mal ton code... Si tu veux j'en ai ici personne ne sait en quel langue sont les commentaires... mais c'est pas tres grave... il n'y en pas bcp Effectivment sa parait bon... il sagirait alors d'un effet de bord, et sans un purify ou un debugger c'est difficile... tu es sous linux, tu n'as pas ddd ? debugger une lib c'est comme un executable, mais il faut un executable de test... ca tombe bien tu l'as au pire fait des printf a plusieurs niveaux, dans le main y compris... surveilles bien ce qui se passe lors de l'appel de la fonction... |
Ben c'est ce que je fais, et je trouve rien de bizarre...
sauf que je peux pas acceder a la variable essai depuis la fonction de la librairie...
ddd je l'ai, mais le blem c'est que je bosse sous solaris via ssh, donc ddd ben...
Va falloir que je rapatrie tout ca chez moi ce soir pour tester le debuggueur...
Et ce soir personne sera la pour m'aider
Donc si quelqu'un sait ce que je peux faire, ca m'arrangerai beaucoup
Car avec le debugguer je vois pas ce que je peux changer...
Marsh Posté le 30-10-2002 à 02:25:19
New probleme : copie du resultat dans un tableau...
j'apelle cette fois la fonction myRecv :
Fonction myRecv que voici, dans une autre librairie :
Je fais rien de bien mechant : je prends un packet sur le reseau, le mets dans la struct, et je veux copier un champ de mon packet dans le aprametre data pour que l'utilisateur fasse mumuse avec...
Et a chaque fois que je lance ca j'ai une segmentation fault...
Quelqu'un peux m'expliquer ?
C'est lie au fait que myRecv est dans une librairie differente ?
Je comprends vraiment pas
Old-probleme :
kikoo
J'ai un petit probleme bien chiant en ce moment ( on a eu un delai supp de 3 jours la ( ) )
En fait, je dois faire une sorte de transport process.
Je vais pas vous donner les details, mais pour envoyer un packet sur le reseau, je ne dois plus utiliser les fonctions classiques du C, mais utiliser une librairie faite par moi meme qui utilise les fonctions classique du C.
C'est un programme de fac donc
Bref, je dois utiliser la fonction :
void mySend(int sockfd, char* data, char* dest_IP, int dest_port);
Avant, je sendais des structs.
Maintenant, je dois envouer des char*, donc j'utilise des unions :
ou 200 est la taille de ma structure.
Vous suivez ?
AInsi, je remplit mon paquet comme avant, et j'ai plus qu'a filer a mysend le tableau buffer de l'union...
Maintenant j'ai un souci.
Le buffer est un char [] . Pas vraiment une chaine donc. il ne se termine pas par '\0' car il represente en fait une "zone" memoire.
Or, pour l'envoyer, faut bien que je le copie dans une struct quelconque qui va aprtir sur le net, dans la fonction mysend.
par exemple :
Je dois copier le contenu du parametre char* dans le champ data de ce paquet pour l'envoyer.
Or :
strcpy ne marche pas a cause du \0 manquant.
strlen c pareil ( m'en doutais apres le 1er m'enfin ).
Je ne peux pas copier caractere par caractere dans un tableau, car je ne connait pas la taille du tableau passe en parametre.
Sans faire de modifications en dehors de am librairie, quel option aie-je pour copier le contenu du tableau en parametre dans mon packet ?
Si je dois obligatoirement faire une modif dans le programme utilisant ma librairie... comment le faire le plus simplement selon vous ? ( je vois deja le for se pointer avec d'un cote un tableau ( la on connait sa taille), de l'autre un char*, ou on initialise la fin a \0, mais je veux eviter ca).
Merci beaucoup
PS : Je ne peux pas rajouter de fonctions dans la librairie, et je n'ai pas le droit d'en changer les specifs
Message édité par Tetedeiench le 31-10-2002 à 20:45:05