petit resume de la situation :    
   
j'ai ma connection tcp entre mon serveur et mon client associee a un file descriptor    
je peux sans probleme lire et ecrire dans ce file descriptor    
   
or, j'ai besoin d'un stream (FILE *) pour pouvoir parser avec lex/yacc ce que le client envoie a mon serveur    
   
je "transforme" le file descriptor en stream grace a la fonction fdopen    
   
j'arrive a ecrire dans ce stream pour envoyer des infos (je le fais juste pour tester que le stream fonctionne car mon but principal est de recevoir des infos et non d'en envoyer, du moins pour l'instant)    
   
je viens de decouvrir que je recevais bien les donnees du client dans le serveur via le stream mais qu'elles n'arrivaient que quand la connection tcp se coupait    
   
en gros, j'etablie la connection client/serveur, j'envoie des donnees du client vers le serveur mais je ne "recois" rien au niveau du serveur<    
je coupe la connection au niveau du client, et la, comme par magie les infos arrivent au serveur    
   
il s'agit donc clairement d'un probleme de bufferisation des donnees dans le stream    
   
le probleme, c'est que les fonctions de la famille setvbuf (qui servent a regler le mode de bufferisation d'un stream) n'ont aucun effet sur mon stream  
 
PS: si vous savez comment utiliser lex/yacc avec autre chose qu'un stream (genre un file descriptor), je suis aussi preneur

[jfdsdjhfuetppo]--Message édité par titoine42--[/jfdsdjhfuetppo]

je viens de lire en entier le man de fdopen et j'ai trouvé ça:
 
The fdopen() function associates a stream with the existing file descriptor, fildes.  The mode of the stream must be compatible with the mode of the file descriptor.  The stream is positioned at the file offset of the file descriptor.
 
sachant que mon fd est en read/write et que je lui demande seulement du read ça devrait fonctionner?

moi j'utilise pas fdopen pour mon client irc ... mais les fonctions bien standard genre read :
 
char data_arrive[1024];
read(sock_actif,data_arrive,200);
 
pis apres, y a pu k'a !

je n'ai pas vraiment, le choix sachant que j'utilise lexyacc, il me faut un FILE *

 
Ca veut dire que le file descriptor que tu passe en argument à fdopen() et le mode d'ouverture de fdopen() doivent être les même.
 
si tu mets ton fdopen() en r et que ton fd de base est en r/w, je pense que ca doit déconner.

j'ai essayer de mettre exactement le meme mode d'ouverture mais ça ne change rien
 
je suis en discussion avec un prof pour trouver où ça peux merder

un prof m'a dit que le problème venait du fait que c'est bufferisé
 
j'ai donc utilisé la fonction setvbuf pour mettre en buffer ligne à ligne mais sans succes.
 
j'ai aussi essayé en passant le stream en mode non bufferisé mais ça ne change rien  

tu peux faire un perror() dérrière le fdopen, qu'on voit ce qu'il se passe ?
 
d'aillieurs si le fdopen échoue, y retourne pas NULL ?

bonne idée, j'ai pas testé la valeur de retour du fdopen

le fdopen me renvoie un pointeur non-NULL donc il fonctionne  
 
si j'ouvre en read/write et que je fais un fprintf sur le stream, les donnees sont bien transmises de l'autre cote    
 
le probleme, c'est que ce qui m'interresse, c'est lire le stream et pas ecrire dedans

si tu fais un fread() dans un tampon, et que tu puts() ce tampon, y'a bien quelque chose ?
 
c'est pas le fscanf qui échoue ? (n'oublies pas que la famille de scanf() retournent le nombre d'éléments convertis...)

petit resume de la situation :  
   
 j'ai ma connection tcp entre mon serveur et mon client associee a un file descriptor  
 je peux sans probleme lire et ecrire dans ce file descriptor  
   
 or, j'ai besoin d'un stream (FILE *) pour pouvoir parser avec lex/yacc ce que le client envoie a mon serveur  
   
 je "transforme" le file descriptor en stream grace a la fonction fdopen  
   
 j'arrive a ecrire dans ce stream pour envoyer des infos (je le fais juste pour tester que le stream fonctionne car mon but principal est de recevoir des infos et non d'en envoyer, du moins pour l'instant)  
   
 je viens de decouvrir que je recevais bien les donnees du client dans le serveur via le stream mais qu'elles n'arrivaient que quand la connection tcp se coupait  
   
en gros, j'etablie la connection client/serveur, j'envoie des donnees du client vers le serveur mais je ne "recois" rien au niveau du serveur<  
je coupe la connection au niveau du client, et la, comme par magie les infos arrivent au serveur  
   
il s'agit donc clairement d'un probleme de bufferisation des donnees dans le stream  
   
le probleme, c'est que les fonctions de la famille setvbuf (qui servent a regler le mode de bufferisation d'un stream) n'ont aucun effet sur mon stream
 
PS: si vous savez comment utiliser lex/yacc avec autre chose qu'un stream (genre un file descriptor), je suis aussi preneur

[jfdsdjhfuetppo]--Message édité par titoine42--[/jfdsdjhfuetppo]

un fflush() ptet ?

déjà essayé le flush  

 
pour une fois ke je pense pouvoir repondre a une kestion prog, il a fallut ke kkun dise ce ke je voulais dire avant moi
 
c pô juste, rho pis je repond kan meme !    
 
essai fflush(descripeur);

de toute façon, même si le fflush fonctionnait, il me serait impossible de l'utiliser sachant que je ne contrôle pas la lecture au niveau de lex

ha heu... bah, modifie le fichier c generer par lex    
 
pour tester... tu verra si ca marche comme ca au moins

Phod a écrit a écrit : ha heu... bah, modifie le fichier c generer par lex       pour tester... tu verra si ca marche comme ca au moins

 
j'aimerais éviter ce genre de solutions
 
en plus, si tu voyais le code généré par flex

[jfdsdjhfuetppo]--Message édité par titoine42--[/jfdsdjhfuetppo]

un 0 de fin de chaine peut-etre ? un EOF ?

 
   explique un peu parce que je ne comprends pas vraiment ta suggestion

note que j'avais modifier lex/yacc pour qu'il ne lise plus a partir d'un FILE * mais d'un truc a moi
 
 
Ca marchait, mais le faire , quelle galere !

 
c'est ce que je suis en train de faire : je recode la macro YY_INPUT

G REUSSI  
 
J'ai recode la macro de lecture d'entree de lex avec des getc au lieu de fread et ca roule  

 
mumuse toi bien....
 
(je ne le referais JAMAIS tellement c t horrible . Ca pis modifier les input de la ZLib . Grand dieux, quel code de cochon ! )