Je vous le prendrais avec plaisir ! (Je suppose qu'il est en ordre de marche).
Écrivez moi afin de déterminer les modalités: panda (aro_base) thisis (dot) be. Vivant en Belgique, je payerai la différence de frais de ports.
Pour préciser, tu n'ajoute pas une IP à une carte ethernet, tu rajoute des ports à ton bridge (i.e. des portes de ton switch virtuel) qui sont soit une carte réseau, soit une interface tun/tap qui va servir de lien avec la carte ethernet virtualisée dans la VM.
Ensuite tout se passe comme si c'était un vrai switch. Note: tu peux ajouter plusieurs IP à nimporte quelle interface ethernet, c'est orthogonal au switch qui permet d'aggréger plusieurs interfaces sur un même média.
Ben apparemment c'est pas possible vu que les capabilities autorisées par le fichier sont toujours vérifiées, donc il faut qu'elles y soient... Il n'y a que les capabilities héritables qui subsistent.
Pourquoi ne pas faire un simple script SETUID que tes utilisateurs pourront lancer sur les binaires qu'ils créent ?
Note essaye quand même de lire la doc correspondant à ta version et non à la 9.1... Le vacuum full a été réécrit pour la version 9.
À part cela, ton analyse me semble correcte... Peux-tu essayer de voir l'espace utilisé par les différents objets ? (commande \dS+ iirc, p-ê pas encore dispo dans la 8.4)
Effectivement tu as bien raison. C'est que je trouve le C dégueu en général (enfin y a bien pire hein, et puis on a pas toujours le choix ;) )
Sinon pour la clareté, quid d'utiliser une variable temporaire, ou d'aliaser ton pointeur que le compilo optimise de toute façon. Histoire que le relecteur ne doivent pas, lui aussi, se taper la lecture du man pour comprendre toutes les subtilités :p genre avoir un *(items+i)=newItem. Bon c'est vrai que c'est une histoire de goût, mais ça t'aurais sûrement permis d'éviter le bug dès le départ.
Bon aller ok je te l'accorde mais je trouve pas cela très lisible. Tant qu'à faire dans le dégueu, tu pourrais essayer getline((*(items+i)=0,items+i),...) (suis pas sur que ce soit du C valide par contre)
As-tu penser à corriger ton utilisation de &itemLen ? Si non, enlève-le il ne sert à rien, sauf p-ê à perturber le relecteur.
Essaye de toutes les afficher à chaque itération...
Le truc c'est que tu avance ton pointeur d'une seule "case" à la fois, donc getline écrase tout ce qui se trouve à la suite de cette case... Aussi, tu lui passe un pointeur "invalide" dans le sens qu'il est illegal pour appeller realloc (ce que getline fait forcément vu que itemLen=0*) car ce n'est plus l'addresse retournée par malloc -> bug (cf. man realloc). Bref t'essaye de mettre dans la zone pointée par ton char** en même temp et un tableau de pointeur et des strings... Contente toi de passer un null à getline, il va t'allouer ta ligne tout seul ensuite t'as plus qu'à ajouter le pointeur à ton tableau comme tu le fais (il me semble) correctement.
newItem = NULL;
while ( getline(&newItem,0,fp) != -1) { ... ajout de newItem à items; newItem=NULL};
Aussi, again, lis les man page de chaque fonction que tu utilise !!! et ne code que lorsque tu es sûr d'avoir compris PARAMETERS et RETURN VALUES.
*:ensuite itemLen est mal utilisé vu que tu ne comptes pas le fait que tu avance le pointeur, pour rester cohérent, tu devrais réduire itemLen. Néanmoins, cela changera rien au fait que getline ne peut pas faire de realloc dessus -> tjrs un bug.
Je suppose que tu essaye d'enregister chaque ligne... Petit exercice, essaye de les afficher à chaque itération. Tu vois où est ton erreur ?
Un indice: vu que chaque ligne est supposée de longueur différente (et à priori, inconnue); tu ne peux pas utiliser un simple tableau à 2 dimensions. (Enfin si tu pourrais mais ce ne serait ni simple ni efficace, je te laisse chercher pourquoi, cela serait un bon exercice ceci dit :p).
La solution c'est d'allouer un buffer pour chaque ligne (cf. man, getline va faire une realloc dessus s'il est trop petit) et d'ajouter son addresse dans ton tableau, que tu devra effectivement redimentionner à chaque coup.
Bon ok j'ai compris maintenant ;-) C'est normal, gcc n'a aucun moyen de savoir que tu ne vas pas utiliser tous les symboles d'un objet que tu lies, ou que cet objet n'utilise pas lui-même tous ses propres symboles. Car cette information est uniquement connue au moment de la compilation d'une unité. Exemple: A.c defini FA() mais ne l'utilise pas, lorsque gcc le compile, il n'enlève pas FA() car il pourrait-être utilisé dans une autre unité; lorsque tu linke ton B.o (qui n'utilise toujours pas FA()) à A.o, gcc ne sait plus que FA() n'est pas utilisé par A.c et ne peut donc l'enlever. Regarde du côté de http://gcc.gnu.org/wiki/LinkTimeOptimization qui doit répondre à ce problème. Je n'en sais pas plus, désolé. Peut-être vas-tu devoir recompiler binutils et gcc pour cela.
PS: Si tu ne les connaissais pas, les outils nm, objdump et strip devraient pouvoir t'aider à voir ce qu'il se passe.
[^] # Re: [RÉSOLU] vim diff en mode caractère
Posté par benja . En réponse au message [RÉSOLU ] vim diff en mode caractère. Évalué à 1.
Cool !
# Ça m'intéresse
Posté par benja . En réponse au message Vends pandaboard. Évalué à 1.
Bonjour,
Je vous le prendrais avec plaisir ! (Je suppose qu'il est en ordre de marche).
Écrivez moi afin de déterminer les modalités: panda (aro_base) thisis (dot) be. Vivant en Belgique, je payerai la différence de frais de ports.
[^] # Re: probleme reseau classique
Posté par benja . En réponse au message Partager une connexion PPP. Évalué à 2.
Réponse courte: oui.
Pour préciser, tu n'ajoute pas une IP à une carte ethernet, tu rajoute des ports à ton bridge (i.e. des portes de ton switch virtuel) qui sont soit une carte réseau, soit une interface tun/tap qui va servir de lien avec la carte ethernet virtualisée dans la VM.
Ensuite tout se passe comme si c'était un vrai switch. Note: tu peux ajouter plusieurs IP à nimporte quelle interface ethernet, c'est orthogonal au switch qui permet d'aggréger plusieurs interfaces sur un même média.
[^] # Re: jailbreak, piratage et matos pas libre
Posté par benja . En réponse au message Ipod touch et amarok. Évalué à 1.
Est-ce vraiment illégal, en France/Europe/... ?
[^] # Re: création de fichier qui sera executé en fork.
Posté par benja . En réponse au message POSIX capabilities / ouvrir port tcp <=1024. Évalué à 1.
Ah oui en effet ! X 2 :) merci
[^] # Re: création de fichier qui sera executé en fork.
Posté par benja . En réponse au message POSIX capabilities / ouvrir port tcp <=1024. Évalué à 2.
Ben apparemment c'est pas possible vu que les capabilities autorisées par le fichier sont toujours vérifiées, donc il faut qu'elles y soient... Il n'y a que les capabilities héritables qui subsistent.
Pourquoi ne pas faire un simple script SETUID que tes utilisateurs pourront lancer sur les binaires qu'ils créent ?
[^] # Re: Problème de VACUUM ?
Posté par benja . En réponse au message Fragmentation database avec PgSQL 8.1. Évalué à 1.
Note essaye quand même de lire la doc correspondant à ta version et non à la 9.1... Le vacuum full a été réécrit pour la version 9.
À part cela, ton analyse me semble correcte... Peux-tu essayer de voir l'espace utilisé par les différents objets ? (commande \dS+ iirc, p-ê pas encore dispo dans la 8.4)
[^] # Re: vive le man
Posté par benja . En réponse au message getline et realloc sont dans une boucle. Évalué à 2.
Effectivement tu as bien raison. C'est que je trouve le C dégueu en général (enfin y a bien pire hein, et puis on a pas toujours le choix ;) )
Sinon pour la clareté, quid d'utiliser une variable temporaire, ou d'aliaser ton pointeur que le compilo optimise de toute façon. Histoire que le relecteur ne doivent pas, lui aussi, se taper la lecture du man pour comprendre toutes les subtilités :p genre avoir un *(items+i)=newItem. Bon c'est vrai que c'est une histoire de goût, mais ça t'aurais sûrement permis d'éviter le bug dès le départ.
Aller, bonne continuation !
[^] # Re: vive le man
Posté par benja . En réponse au message getline et realloc sont dans une boucle. Évalué à 1.
Bon aller ok je te l'accorde mais je trouve pas cela très lisible. Tant qu'à faire dans le dégueu, tu pourrais essayer getline((*(items+i)=0,items+i),...) (suis pas sur que ce soit du C valide par contre)
As-tu penser à corriger ton utilisation de &itemLen ? Si non, enlève-le il ne sert à rien, sauf p-ê à perturber le relecteur.
[^] # Re: vive le man
Posté par benja . En réponse au message getline et realloc sont dans une boucle. Évalué à 1.
Oui et, quel est l'intérêt ?
[^] # Re: vive le man
Posté par benja . En réponse au message getline et realloc sont dans une boucle. Évalué à 2.
Un memset (même correctement utilisé :p) pour mettre un pointeur à null, c'est un peu overkill, non ? *(items+i)=0;
[^] # Re: vive le man
Posté par benja . En réponse au message getline et realloc sont dans une boucle. Évalué à 2.
bien vu j'allais le signaler aussi ;)
[^] # Re: Je suppose...
Posté par benja . En réponse au message getline et realloc sont dans une boucle. Évalué à 1.
'fin à ce momemt là (itemLen=0) ce n'est pas un bug vu que items+i = items, ensuite cela le devient...
[^] # Re: Je suppose...
Posté par benja . En réponse au message getline et realloc sont dans une boucle. Évalué à 1.
Essaye de toutes les afficher à chaque itération...
Le truc c'est que tu avance ton pointeur d'une seule "case" à la fois, donc getline écrase tout ce qui se trouve à la suite de cette case... Aussi, tu lui passe un pointeur "invalide" dans le sens qu'il est illegal pour appeller realloc (ce que getline fait forcément vu que itemLen=0*) car ce n'est plus l'addresse retournée par malloc -> bug (cf. man realloc). Bref t'essaye de mettre dans la zone pointée par ton char** en même temp et un tableau de pointeur et des strings... Contente toi de passer un null à getline, il va t'allouer ta ligne tout seul ensuite t'as plus qu'à ajouter le pointeur à ton tableau comme tu le fais (il me semble) correctement.
newItem = NULL;
while ( getline(&newItem,0,fp) != -1) { ... ajout de newItem à items; newItem=NULL};
Aussi, again, lis les man page de chaque fonction que tu utilise !!! et ne code que lorsque tu es sûr d'avoir compris PARAMETERS et RETURN VALUES.
*:ensuite itemLen est mal utilisé vu que tu ne comptes pas le fait que tu avance le pointeur, pour rester cohérent, tu devrais réduire itemLen. Néanmoins, cela changera rien au fait que getline ne peut pas faire de realloc dessus -> tjrs un bug.
[^] # Re: Je suppose...
Posté par benja . En réponse au message getline et realloc sont dans une boucle. Évalué à 1.
Comme noté plus haut, pas besoin de d'allouer un buffer toi-même si tu passe une addresse null à getline. 'bref
# Je suppose...
Posté par benja . En réponse au message getline et realloc sont dans une boucle. Évalué à 1.
Je suppose que tu essaye d'enregister chaque ligne... Petit exercice, essaye de les afficher à chaque itération. Tu vois où est ton erreur ?
Un indice: vu que chaque ligne est supposée de longueur différente (et à priori, inconnue); tu ne peux pas utiliser un simple tableau à 2 dimensions. (Enfin si tu pourrais mais ce ne serait ni simple ni efficace, je te laisse chercher pourquoi, cela serait un bon exercice ceci dit :p).
La solution c'est d'allouer un buffer pour chaque ligne (cf. man, getline va faire une realloc dessus s'il est trop petit) et d'ajouter son addresse dans ton tableau, que tu devra effectivement redimentionner à chaque coup.
[^] # Re: L'expérience démocratique
Posté par benja . En réponse au journal Projet de démocratie participative. Évalué à 1.
http://demexp.net/dokuwiki/fr:faq_du_projet_politique?rev=1306932462
https://lists.nongnu.org/archive/html/demexp-dev/
:-)
[^] # Re: L'expérience démocratique
Posté par benja . En réponse au journal Projet de démocratie participative. Évalué à 1.
Non.
# L'expérience démocratique
Posté par benja . En réponse au journal Projet de démocratie participative. Évalué à 2.
Pour la partie technique, tu peux sans doute aller voir ce qui se fait de ce côté : http://www.demexp.org/dokuwiki/start
Vu que le wiki s'est fait vandalisé, http://webcache.googleusercontent.com/search?q=cache:ETf5ZhNzdpUJ:www.demexp.org/dokuwiki/fr:telechargement_du_logiciel_demexp+site:demexp.org+telecharger&cd=3&hl=en&ct=clnk
[^] # Re: En résumé…
Posté par benja . En réponse au journal Décence et respect autour d'un décès. Évalué à 1.
s/espaces/espaces fines/
</tantquàfaire>
[^] # Re: Pour info
Posté par benja . En réponse au journal Survivre en milieu hostile. Évalué à 2.
Ce n'est pas ce que j'ai entendu/lu... Tu ne fais pas de X forwarding je suppose ?
http://www.google.be/search?q=putty+windows+7+crash
[^] # Re:J'ai séparé ma classe en 2 fichiers .h et .cpp et le code est plus gros
Posté par benja . En réponse au message Faire une réduction de code en supprimant les fonctions non utilisées. Évalué à 1.
Cool comme astuce :-) As-tu eu l'occasion de tester le LTO ?
[^] # Re: Template programming
Posté par benja . En réponse au message Faire une réduction de code en supprimant les fonctions non utilisées. Évalué à 0.
[^] # Re: Template programming
Posté par benja . En réponse au message Faire une réduction de code en supprimant les fonctions non utilisées. Évalué à 1.
Bon ok j'ai compris maintenant ;-) C'est normal, gcc n'a aucun moyen de savoir que tu ne vas pas utiliser tous les symboles d'un objet que tu lies, ou que cet objet n'utilise pas lui-même tous ses propres symboles. Car cette information est uniquement connue au moment de la compilation d'une unité. Exemple: A.c defini FA() mais ne l'utilise pas, lorsque gcc le compile, il n'enlève pas FA() car il pourrait-être utilisé dans une autre unité; lorsque tu linke ton B.o (qui n'utilise toujours pas FA()) à A.o, gcc ne sait plus que FA() n'est pas utilisé par A.c et ne peut donc l'enlever. Regarde du côté de http://gcc.gnu.org/wiki/LinkTimeOptimization qui doit répondre à ce problème. Je n'en sais pas plus, désolé. Peut-être vas-tu devoir recompiler binutils et gcc pour cela.
PS: Si tu ne les connaissais pas, les outils nm, objdump et strip devraient pouvoir t'aider à voir ce qu'il se passe.
[^] # Re: J'ai noté...
Posté par benja . En réponse au message solution d'édition de données relationnelles. Évalué à 2.
http://www.glom.org/