Étienne a écrit 707 commentaires

Donc ils préfèrent qu'on perde du temps à faire la requête dhcp quand on veut le réseau et attende la réponse plutôt que d'activer le réseau en tache de fond?

Je pense plutôt qu'ils démarrent le service NetworkManager. Le service est démarré mais la récupération d'une adresse peut être faite après par NetworkManager pendant que le reste démarre.

La différence c'est que gets est impossible à utiliser de façon sûre, ce qui n'est pas le cas de strcpy(). Il faut simplement avoir fait la vérification de taille avant l'appel de strcpy().


Étienne

Je rajouterai ceci :
#define mavar toto##__FILE__
int mavar;


Ne marchera jamais car __FILE__ est une chaîne de caractères entouré comme il se doit par des ", ce qui ne risque pas de te donner un nom de variable valide. Au mieux tu te retrouvera avec
int toto"toto.c";

Qui risque de difficilement compiler.

Étienne

Je suis curieux de savoir comment ça résout le problème exposé :

J'ai un fichier en C sur lequel le cpp va passer plusieurs fois pour créer plusieurs version du code. Genre gcc -E test.c > v1.c && gcc -E test.c > v2.c , etc etc
Au final, je vais tout lier ensemble, et ça bloque à cause de définitions multiples de certains symboles


Petit rappel :
Je ne peux pas définir de macro en cli (en utilisant -D), les fichiers doivent utiliser la même commande exactement.


Je suis sûr que les blaireaux seront content d'apprendre quelque chose.

Étienne

Les extensions de protocole eow@openssh.com et no-more-sessions@openssh.com ne sont envoyés uniquement aux serveurs s'annonçant comme étant OpenSSH.

extension étant féminin, il faut accorder envoyées

Pour la négation, il faudrait soit mettre ... sont uniquement envoyées aux serveurs... ou bien ne sont envoyées qu'aux serveurs...

Sinon félicitation pour l'exhaustivité de la dépêche.

Étienne

Si tu fais du C++, tu peux commencer par regarder du côté de boost.endian (ça ne fait pas encore partie de boost mais ça ne devrait pas tarder). Voir http://mysite.verizon.net/beman/endian-0.10/libs/integer/doc(...) et http://svn.boost.org/svn/boost/sandbox/endian pour les sources.

Le principe est assez simple, tu a une classe endian templatée par le type d'endian, le type C représenté et la taille du champ. La donnée stockée sera toujours dans le format de l'endian que tu as fourni.
Ensuite les différents opérateurs sont implémentés pour fournir une interface identique à un entier mais qui fait la conversion dans le format de ta machine à chaque fois.


Étienne

si je mets un char* j'ai un bus error lorsque j'initialise ma chaine de caractère !


Il faut quand même allouer ton buffer.

Je te propose de faire quelquechose du genre (dans main.y) :


char* g_str = NULL;
size_t g_str_size;
size_t g_str_read;

int set_parse_string(char* str)
{
size_t length = strlen(str);
if (g_str != NULL) free(g_str);

g_str = (char*) malloc(length+1);
if (g_str == NULL) return 0;

strcpy(g_str, str);
g_str_size = length;
g_str_read = 0;

return 1;
}


et dans ton main :

int main(void) {
value = 0;
state = off;

/* première suite de commandes à parser (ici il n'y en a qu'une) */
set_parse_string("set temperature 12");
yyparse();

/* deuxième suite de commandes à parser */
set_parse_string("get temperature heat");
yyparse();

return 0;
}

Numérique, pas digitale l'horloge !

Sauf si les utilisateurs d'Ubuntu doivent compter sur leurs doigts pour savoir quelle heure il est ;)

En regardant vite fait, il semble que tu as 2 problème :
- je ne pense pas que tu puisse faire un "extern char*" et déclarer un "char[]", il faut transformer dans main.y ton g_str en char*
- tu ne calcule pas g_str_size et g_str_read
- il me semble que ton fichier doit finir par une fin de ligne (cf commands dans main.y), et donc soit tu supprime le TOK_EOL de la fin de commands, soit tu rajoute un \n à la fin de ta chaine de caractères.


Étienne

Voici un mini programme pour flex qui va simplement afficher le contenu de la chaine de caractère g_str :

Sinon dans ton programme, j'ai l'impression que tu n'initialise jamais g_str_size et g_str_read, le mieux est sans doute d'avoir une fonction set_parse_string() qui va positionner correctement g_str, g_str_size et g_str_read.



%{
#include <string.h>

#undef YY_INPUT
#define YY_INPUT(b,r,ms) { r = my_yyinput(b,ms); }

char g_str[] = "toto tata tutu\n";
size_t g_str_size = sizeof(g_str);
int g_str_read = 0;


int my_yyinput(char* buf, int max_size)
{
    int reste = g_str_size-g_str_read;
    int num = (max_size < reste ? max_size : reste);

    if (num > 0)
    {
        memcpy(buf, g_str+g_str_read, num);
        g_str_read += num;
    }
    return num;
}
%}

%%
%.|\n    ECHO;
%%


Étienne

Il est sans doute toujours possible de ne remplir qu'un caractère à la fois mais tu perd en performance à cause de la bufferization qui ne se fait plus.

Étienne

Tu peux regarder les sources ici : http://www.sfr-fresh.com/unix/misc/am-utils-6.2a2.tar.gz:a/a(...)

En particulier les lignes 90 à 108 et la fonction sun_map_input ligne 205 qui fait exactement ce que tu cherche.

Étienne

La fonction my_yyinput ressemblerait à (je n'ai pas testé le code) :



extern char* g_str;
extern size_t g_str_size; /* taille de g_str */
extern int g_str_read; /* nombre de caractère déjà envoyés à lex, initializé au départ à 0 */

int my_yyinput(char* buf, int max_size)
{
    /* on calcule le nombre de caractères à copier dans buf,
     * soit on a assez de caractères pour remplir, buf, soit on prend le reste de la chaine
     */
    int num = min(max_size, g_str_size-g_str_read);
    

    /* on copie notre chaine dans buf */
    if (num > 0)
    {
        memcpy(buf, g_str+g_str_read, num);
        g_str_read += num;
    }
    return num;
}


La macro YY_INPUT est appelée par flex pour reremplir le buffer interne sur lequel il travail. Ce qui permet d'optimiser la lecture en ne lisant pas caractère par caractère comme c'était le cas de lex d'AT&T. Donc ta fonction my_yyinput va être appelée à chaque fois que le buffer interne de flex est vide et tu lui donne la suite de ta chaîne.

Étienne

Cette solution est spécifique à flex (il n'y a pas de solution générique pour toutes les implémentations de lex) mais tu peux redéfinir la macro YY_INPUT.

Tu dois pouvoir faire quelque comme ceci :


%{
#under YY_INPUT
#define YY_INPUT(b,r,ms) (r = my_yyinput(b, ms))
%}

int my_yyinput(char* buf, int max_size)
{
//on peut copier dans buf au maximum max_size octets et renvoyer le nombre d'octets copiés
}



Étienne

Le mirroir fait un "downgrade" (pour annuler la mise à jour). Yum refusera d'installer le vieux paquet. Il refuse par défaut tout downgrade. "Pire", si un paquet ne peut être mis à jour car un autre paquet l'empêche, Yum signale une erreur. Par exemple si le craket a mis un paquet avec "require kernel = 2.6.28.6-52" et qu'il y a un kernel supérieur, il y a alors une erreur. NB: dans ton scénario le cracker ne peut fixer la version, il doit utiliser une vieille version.

Ou alors le cracker rajoute une dépendance que tu n'as pas installée, dans une vieille version trouée et empêche ceux qui l'avaient de faire la mise à jour.

Je ne sais pas si c'est réaliste, mais il me semble que pour quelqu'un de motivé (qui veut se faire un petit réseau de zombies à revendre), il pourrait :
- monter un serveur avec une bonne connexion et une bonne bande passante
- proposer ses services à fedora (ou un autre) pour fournir un miroir
- faire un miroir de fedora
- avec le plugin de yum permettant de sélectionner automatiquement le miroir qui répond le plus vite, le cracker n'a même pas besoin de faire la pub de son miroir, les utilisateurs de fedora qui sont proche de lui vont automatiquement l'utiliser
- lorsqu'un outil peu déployé voit une mise à jour de sécurité, il peut modifier les métadonnées par rapport au dépôt officiel pour faire installer le paquet dans la version trouée en tant que dépendance d'un paquet installé chez tout le monde (par exemple en dépendance de coreutils).
- ceux qui n'avaient pas ce paquet installé l'installent dans une version trouée
- pour ceux qui l'avaient déjà ils ne voient même pas qu'il y a une mise à jour à faire et gardent la version moisie
- en primer il se constitue automatiquement une liste des IP qui ont sa version vérolée

C'est exactement ça, en pratique c'est surtout utilisé pour les petits fichiers de configuration par exemple, mais ça marche aussi pour de gros fichiers. Comme tu dis l'objectif c'est d'avoir un fichier complet, soit toujours en ancienne version, soit dans la nouvelle version.

Dans son post, il explique que c'est une utilisation très courante que de passer par de petits fichiers par exemple pour les configurations. Et d'ajouter qu'on est d'accord pour perdre une modification, mais pas pour mettre toute sa conf en vrac.

Le problème lié à ext4 c'est que les le filesystem ne garantie pas que les modifications seront faite dans l'ordre où elles ont été appelées. Donc le rename peut survenir avant le write() en pratique car les modifications sur les données sont gérées séparément des modifications sur la table des inodes de ce que j'ai pu comprendre. En faisant son rename() à la fin (le rename doit être atomique, en tout cas on n'a pas une fenêtre d'ouverture de 50 secondes) on se dit que si tous le reste a été effectué, alors seulement on fera le rename(), si un plantage a eu lieu avant d'arriver au rename(), on aura au pire un fichier en trop sur le filesystem mais on aura gardé l'ancienne configuration.

Pour apporter un autre point de vue, voir http://mjg59.livejournal.com/108257.html

Sa position est de dire que le pattern qui consiste à faire un open("foo.tmp"), write(), close() and then rename("foo.tmp", "foo") devrait correctement fonctionner, c'est à dire que l'on s'attend à avoir un fichier foo qui a soit l'ancienne version, soit la nouvelle version étant donné que rename() est atomique. Mais en aucun cas on ne devrait avoir de perte de données en cas de crash.
Le fait de préconiser un fsync() est une fausse solution d'après lui, car on ne cherche pas à garantir que le fichier est écrit, on cherche à garantir que le fichier sera dans un état correct et on n'a pas besoin de sans arrêt synchroniser sur le disque pour cela.


Étienne

Et comme à chaque fois, la réponse est : « Donnes-nous la version robuste aux espaces dans les noms de fichiers » (et j'anticipe sur la réponse à la réponse : et la version robuste aux retours chariots dans les noms de fichiers ?).

$ ls -1
toto tutu
toto?tutu
$ for i in *; do readlink -f "$i"; done
/tmp/test/toto tutu
/tmp/test/toto
tutu


Çà ne me parait pas insurmontable.

Étienne

On peut aussi citer lcov[1] qui permet de générer des rapports[2] très pratiques. Le seul problème, qui vient certainement de gcc, c'est que pour la couverture du code présent dans les en-têtes (typiquement du code de template c++), ce n'est pas terrible.

Étienne

[1] : http://ltp.sourceforge.net/coverage/lcov.php
[2] : http://ltp.sourceforge.net/coverage/lcov/output/index.html

J'y réfléchis :) Cela dit, si quelqu'un a une super idée pour l'implémenter, je suis preneur!

A titre personnel, je pense qu'il serait intéressant pour l'autocomplétion d'avoir les 10 (le nombre est arbitraire) répertoires les plus populaires correspondant au pattern. De la sorte, si je vois que c'est bien le premier de la liste dans lequel je veux aller, je peux valider, sinon je rajoute quelques lettres.


Étienne

1.C'est pas forcement étonnant que quand tu supprime tes fichiers l'espace n'est pas libéré: Si un fichier est encore occupé, le fichier existe toujours, il est juste marqué "à éffacer", et ne le sera effectivement que quand il aura fini (donc à relier avec ce qui est dit au dessus si un programme crée un fichier de 4Go meme si tu le supprime il restera)

Pour trouver la liste des fichiers qui sont supprimés mais toujours ouvert, on peut utiliser :


$ find /proc/*/fd -type f -links 0


Cela peut faire apparaitre des erreurs du style "File system loop detected" qu'une redirection de stderr vers /dev/null ferra disparaitre.

On peut même en récupérer le contenu en copiant le fichier vers un autre endroit. Et en prime on a le pid du fichier qui correspond au sous-répertoire de /proc, par exemple


/proc/3594/fd/3 - > /var/run/dhcpcd-br0.pid (deleted) est un fichier supprimé, qui est toujours ouvert par le programme de pid 3594.

Étienne

Note : le commentaire que je fais ici viens de mes observations et pas du tout de mes connaissances d'OpenBSD, quelqu'un de mieux renseigner aura peut-être des choses à rajouter ou corriger

Je pense que la l'incompréhension du choix de PCC par l'équipe d'OpenBSD vient du fait que l'on ne prend pas en compte toutes les exigences du projet, je vais essayer de les synthétiser.

L'objectif premier est de pouvoir compiler tout le système de base d'OpenBSD, ce changement ne concerne donc pas l'intégralité des ports mais seulement ceux du système de base, et ceci bien sûr pour toutes les architectures gérées par OpenBSD. Ce qui veut dire qu'il faut que ce compilateur :

- puisse compiler suffisamment rapidement et sans consommation excessive de mémoire pour compiler sur les machines peut puissantes. (voir à ce sujet http://www.onlamp.com/pub/a/bsd/2004/03/18/marc_espie.html la réponse à la question What is the plan for gcc3 introduction? (bas de page))

- puisse compiler tout le système de base, dont le compilateur, ce qui signifie qu'il doit pouvoir se bootstraper

- gère correctement l'intégralité des architectures cibles d'OpenBSD. Correctement signifie que la maintenance d'une architecture doit rester le plus simple possible et ne soit pas cassée sans arrêt au grès des commits.

- Ce qui est très important est que les devs puissent facilement faire intégrer leurs modifications, ce qui ne semble pas être le cas sur gcc qui est essentiellement géré par les distributions commerciales Linux et par Apple dont les objectifs ne sont pas toujours conciliables avec ceux d'OpenBSD.

- Sans oublier que les devs OpenBSD sont assez portés sur la sécurité et donc sur la simplicité ce qui, et je ne pense pas qu'on me donnera tord sur ce point, n'est pas la force de gcc.



Étienne

Si Theo pense vraiment que GCC n'est pas maintenu upstream alors il doit vivre dans un monde parallèle au notre. Un monde ou IBM, Red Hat, Novell, Bull, Google, l'INRIA, et de nombreuses autres entreprises et universités ne contribuent pas au développement de GCC (allez donc voir les affiliations des auteurs des articles des différents GCC summits).
Dire qu'on soutient PCC car on trouve que GCC n'est pas maintenu c'est grotesque.

Il me semble avoir lu plusieurs fois des commentaires de Marc Espie se faisant remarquer que seules les architectures x86 et powerpc étaient correctement maintenues et qu'ils avaient régulièrement des problèmes pour les architectures plus exotiques. D'autre part, les dev OpenBSD se plaignent de la difficulté à faire inclure des patchs.

Voir par exemple http://undeadly.org/cgi?action=article&sid=2007091519520(...)


Étienne

Dans tous les cas gprof est ton ami pour savoir ce qui rame le plus (avec lui, j'ai fais parfois des optimisation x4 en voyant des goulots d'étranglements...)

Valgrind avec l'outil callgrind est pas mal également, couplé avec kcachegrind pour exploiter les résultats.


Étienne