Reprise du message précédent :
Tiens tant qu'on parle de word, lorsque qu'on exécute une fusion (avec un mailmerge), le document créé l'est avec un nom particulier, ou se trouve l'option ou on spécifie le nom ?

classique. Nous on avait eu des emmerdes plusieurs fois, quand quelqu'un se plantait dans la casse d'un nom de fichier et corrigeait au commit suivant ...

Je ne comprends pas d'oû vient le bug  , je ne suis pas expert SVN et encore moins sous Windows  

spareil dans TroubledCase, BTW

En fait le pb, je viens de vérifier, c'est que Eclipse s'est chié dans le commit quand j'ai fait le renommage. Il a fait le copy mais pas le delete. Donc il y avait toujours les 2 types de fichiers dans le trunk
J'ai du passer par un svn commit en ligne de commande pour committer le delete et là le checkout sous Windows vient de réussir \o/

le noob moi je les perdais qu'en tombant, au moins

Windows
Eclipse ²

stre bien eclipse

Stray bieng Windows

p'tain mais quand on fait un copy/paste dans word, on peut pas garder le style de destination plutôt que celui d'origine?

collage spéciale -> texte non mis en forme  
ou truc approchant

nan, mais certains logiciels ont un "coller sans mise en forme".

dans le menu "edit"

bon je reformatte tout le texte collé
 
 jveux pas dire, mais Latex c'est mieux

oui mais non justement, j'y ai pensé. c'est soit formaté soit non formaté (dans ce cas il prends même pas le format de destination...)

1 point  

Pas dans la version 2007

non /!\

Dans ces cas-là, je colle sous emacs, je copie et colle sous Word/Thunderbird.
 
et c'est vrai

+1 mais là il craint

Pareil collage dans un éditeur de texte simple (notepad ou gedit suivant les plateformes).

bon, j'aurai besoin de sniffer une connexion TCP sous OS X, si l'outil savait filtrer pour me montrer que la request et la response d'une connexion HTTP vers une URL précise, ça serait top moumoute. Vous avez un outil ?

bourdel
 
Mon téléchargement de Ghosts I-IV a foiré, j'ai un peu trop retry et maintenant c'est tout cassé

Ethereal/Wireshark, comme tout le monde

T'as ettercap aussi mais... comment dire...

Extension TamperData pour FF

 
Et personne me répond sur le topic Debian sur OSA

Salut à tous,  
 
Je fais actuellement le portage d'un code C de Visual 6 vers un compilateur gcc v3.4 sur RedHat 4.
 
A un moment, un même FILE* est fermé plusieurs fois (fclose (monStream)). A l'exécution sur Visual 6, ça ne pose pas de problème. Mais sur RedHat, ça fait planter l'appli.
 
Est-ce qu'il y a un moyen de vérifier si un stream a déjà été fermé ? J'avais pensé à faire un fread sur le stream, puis à appeler un ferror. Logiquement, si le stream a été fermé, alors fread ne fonctionnera pas et ferror reverra true.
 
En revanche, si le stream n'a été ouvert qu'en écriture, fread échouera systématiquement...
 
Merci de votre aide.

 
je préfère la solution Expect like :x avec le code centralisé.

 
tu mets ton FILE* a NULL après chaque fclose ? :x

Wow

certainement redhat AS4.

merci,  mais là je veux surveiller au niveau plus bas, parce que je soupçonne le serveur.

J'ai pas envie de mareequoter, donc j'en prend une au hasard...
 

 
Au royaume-uni, le standard était du 240V. Ils sont passés au 230V, mais comme d'habitude au R.U, personne n'est au courant (et heureusement, sinon ils nous feraient encore des manifs contre l'oppression du joug européen et tout ça). Donc on considère que c'est du 240 +-6%.
 
En France et pour le reste de l'europe continentale, on est passé récemment du 220V au 230V. Récemment, ça veut dire il y a une vingtaine d'années au moins, hein. Mais comme pour l'ancien franc, la disparition du SMIG, ou l'interdiction de fumer sur les quais de gare, ça va mettre un petit moment à entrer dans les moeurs...
 

mytho, fake

 
Zarb, normalement fclose() ne fait rien sur un flux qui n'est plus associé, non ?

#include <stdio.h>
 
int main(void)
{
   FILE *taiste = fopen("taiste.c", "r" );
   
   if (taiste)
   {
      fclose(taiste);
      fclose(taiste);
      fclose(taiste);
   }
 
   return 0;
}

C'est tout à fait illégal de fermé un fichier plusieurs foit car la zone poitnée par le FILE* est libérée et peut être donc utilisée pour autre chose.
Je te conseille donc de mettre ce pointeur à "null" aprés chaque fclose comme ça tu pourra vérifier si le fichier a déjà été fermé, je te conseille aussi de créer un topic si tu as d'autres problèmes

À noter que fclose(NULL) par contre peut être cause de segfault, s'il y a mise à NULL il faut donc tester avant le FILE* avant de lancer fclose()

#include <stdio.h>
 
int main(void)
{
   FILE *taiste = fopen("taiste.c", "r" );
   
   if (taiste)
   {
      fclose(taiste);
      fclose(taiste);
      fclose(taiste);
   }
 
   return 0;
}

$man fclose
[...]
 Le  comportement  de  fclose() est indéfini si l’argument stream est un
       pointeur illégal, ou si un descripteur a déjà été passé à  une  invoca‐
       tion précédente de fclose().
[...]

 
Ouaip, possible en effet, j'étais pas sûr du comportement de fclose dans ce cas-là.
Ben dans ce cas une seule solution : garder une trace des FILE* et des actions qu'on fait dessus. Si dans un programme on ne sait plus s'il y a eu fclose() ou non, c'est qu'il y a un souci de conception.

#include <stdio.h>
 
int main(void)
{
   FILE *taiste = fopen("taiste.c", "r" );
   
   if (taiste)
   {
      fclose(taiste);
      fclose(taiste);
      fclose(taiste);
   }
 
   return 0;
}

/tmp/ccofbqwG.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
collect2: ld a retourné 1 code d'état d'exécution
 

 
En remplaçant gcc par g++ ça marche.
 

*** glibc detected *** double free or corruption (top): 0x08795008 ***
Abandon
 

 

1/ Pourtant, c'est le concept du C . Ça marche si tu suis la spec, sinon on fait pas de vérif et on verra ce que ça donne (et entre le segfault et la corruption de données, c'est pile ou face)
2/ Ça, je me demande comment c'est possible raisonnablement quand tu restes en C