inotify sur un repertoire: le champs inotify_event.len semble rester=0 pour un repertoire

Bah c'est le compilo qui fait sa tambouille. Une méthode qui m'a l'air de
marcher :
- tu mets les variables de taille fixe stockées au début du bloc
d'activation, tandis que les variables de taille dynamique n'y sont
représentées que par un pointeur
- quand tu crées un tableau dynamique, tu stockes l'adresse du bout
du bloc d'activation dans le pointeur correspondant à la variable en
question, et tu étends de la place nécessaire le bloc d'activation
- quand tu quittes un bloc, tu réduis son bloc d'activation.

Le tout est de savoir si, lors d'un while, for, .... tu quittes bien ton
bloc (en fait, je crois pas: mais ce n'est pas le cas ici: y'a qu'une
variable qui gigotte de taille)

Comme ça, ça reste du LIFO, ça se gère efficacement.

Après, je crois me souvenir qu'on m'avait expliqué qu'il y a des
interactions immondes avec certaines subtilités genre longjmp, qui ne sont
pas encore bien gérées par les compilateurs.

meme gcc maintenant? Il me semble balaise! C"est un monument ce truc!

Comment gererais-tu les "-l", "--listemodifiedfiles", "--", etc....
passes en arguments que j"aimerais traiter

Regarde la fonction getopt (man 3 getopt).

J'en ai vu des critiques....
(Je me rappelle plus ou) Tu gardes ca, a titre personnel?
Ok, alors, j'adopte. Je vais integrer

Zeyes :

tu crois que je devrais supprimer des messages moi-meme,

Surtout pas! Ce thread peut interesser des gens. Même si c'est un peu
bordélique, on a quand même touché pas mal de points intéressants.

La solution, c'est d'être moins bordélique la prochaine fois.

Heu, ca c'est pas possible..... c'est inheret a moi!!!!
Dsole

ou ils vont etre "oublies" dans qq temps....

La plupart des serveurs virent les messages au bout de O(1) semaines. Mais
il y en a qui archivent, par exemple Google.
Ah flute!

Tant pis pour lui!
Il va archiver des aneries.......
En fait je devrais peut-etre IRC-er ?

Zeyes :

Le tout est de savoir si, lors d'un while, for, .... tu quittes bien ton
bloc

Oui.

meme gcc maintenant? Il me semble balaise! C"est un monument ce truc!

Plutôt une usine à gaz, en fait.

Regarde la fonction getopt (man 3 getopt).

J'en ai vu des critiques....
(Je me rappelle plus ou) Tu gardes ca, a titre personnel?

Je ne m'en suis jamais servi en fait. Je ne programme pas tant que ça en C,
voire pas tant que ça du tout, et quand je le fais, c'est plus du bricolage
rapide à interface très rudimentaire.

Zeyes :

Le tout est de savoir si, lors d'un while, for, .... tu quittes bien ton
bloc

Oui.
Ah, je pensais que non.

meme gcc maintenant? Il me semble balaise! C"est un monument ce truc!

Plutôt une usine à gaz, en fait.

Je connais pas l'interne, mais le man est impressionnant!
Et je ne connais pas d'alternative Linux

Regarde la fonction getopt (man 3 getopt).
J'en ai vu des critiques....

(Je me rappelle plus ou) Tu gardes ca, a titre personnel?

Je ne m'en suis jamais servi en fait. Je ne programme pas tant que ça en C,
voire pas tant que ça du tout, et quand je le fais, c'est plus du bricolage
rapide à interface très rudimentaire.

Tant pis... bon Nicolas va pitet reagir........
Parce qu'il a pas l'air d'aimer les trucs rapides pour voir....
Et pis bon, j'aimerais pouvoir exposer mon code sans angoisse!

Zeyes :

Le tout est de savoir si, lors d'un while, for, .... tu quittes bien ton
bloc

Oui.
Ah, je pensais que non.

C'est vraiment dans la logique de la syntaxe. Après, on n'est jamais trop
prudent, jetons un oeil à la norme :

Norme C99, section 6.8.5 :

5 An iteration statement is a block whose scope is a strict subset of the
scope of its enclosing block. The loop body is also a block whose scope is a
strict subset of the scope of the iteration statement.

Je connais pas l'interne,

Je n'y ai jamais mis les pieds, mais on m'en a dit beaucoup de mal. D'autre
part, ça raaaaaaaaaaaaaaaaaaaaaaaaaaaaaaame! Et il n'y a pas si longtemps,
il était très facile de le faire segfaulter sur du code C++ avec un peu trop
de templates.

mais le man est impressionnant!

Quand tu vois toute la marée d'options, tu peux être sur que derrière tu as
un bazar inextricable.

Et je ne connais pas d'alternative Linux

Il y a http://fabrice.bellard.free.fr/tcc/.

Et pis bon, j'aimerais pouvoir exposer mon code sans angoisse!

Personne de sensé n'en aura quoi que ce soit à foutre de la manière dont tu
passes les arguments au programme. Ce qui fait argher les gens, c'est de
voir des appels systèmes dont on ne vérifie pas le succès, ou des écritures
qui risquent de déborder du buffer cible (il y en avait une dans ton code).

Zeyes :

Le tout est de savoir si, lors d'un while, for, .... tu quittes bien ton
bloc
Oui.

Ah, je pensais que non.

C'est vraiment dans la logique de la syntaxe. Après, on n'est jamais trop
prudent, jetons un oeil à la norme :

Norme C99, section 6.8.5 :

5 An iteration statement is a block whose scope is a strict subset of the
scope of its enclosing block. The loop body is also a block whose scope is a
strict subset of the scope of the iteration statement.

Je connais pas l'interne,

Je n'y ai jamais mis les pieds, mais on m'en a dit beaucoup de mal. D'autre
part, ça raaaaaaaaaaaaaaaaaaaaaaaaaaaaaaame! Et il n'y a pas si longtemps,
il était très facile de le faire segfaulter sur du code C++ avec un peu trop
de templates.

mais le man est impressionnant!

Quand tu vois toute la marée d'options, tu peux être sur que derrière tu as
un bazar inextricable.

Et je ne connais pas d'alternative Linux

Il y a http://fabrice.bellard.free.fr/tcc/.

Et pis bon, j'aimerais pouvoir exposer mon code sans angoisse!

Personne de sensé n'en aura quoi que ce soit à foutre de la manière dont tu
passes les arguments au programme. Ce qui fait argher les gens, c'est de
voir des appels systèmes dont on ne vérifie pas le succès, ou des écritures
qui risquent de déborder du buffer cible (il y en avait une dans ton code).
Merci

Bah j'ai vu.... mon nom[1000] etait pas bon pour le service du read....
Mais c'etait un essais, un dimache am, avec une biere, devant la tv....
Et il reste surement des cas d'erreur a verifier... j'avais mis le
minimum pour savoir ou je me plantais. Le but etait simplement de voir
comment ca marche, pas de le publier. Mais je vais peut-etre changer
d'avis, maintenant.. :-)
Merci encore pour tes reponses....

Zeyes :

Mais la longueur totale n'est pas fixe.
L'allocation doit etre refaite a chaque fois (m'enfin presque)
Alors je peux pas utiliser un type defini statique

C'est pour ça que je parlais de tableaux dynamiques. Si je ne me plante pas,
ça donne quelque chose comme :


while (...) {
poll(...);
ioctl(...);
union {char buf[ln]; struct inotify_event blah;} x;
read(jesaispluscommentsappelletonfd,x.buf,ln);
void * i; struct inotify_event * j;
for (i=x.buf,j=&x.blah;x!=(void *)x.buf+ln;
i+=sizeof(struct inotify_event)+j->len,j=i) {
// traiter l'évènement pointé par j
}
}

.
En fouillant dans inotify.c (ce qui est dit aussi dans inotify.txt, mais

j'ai -encore une fois- lu trop vite)
Le len est aligne pour coller a un tableau de inotify_event
Donc:
while (...)
{
poll(...);
ioctl(...,&ln);

inotify_event ev[ln/sizeof(struct inotify_event)];

l=read (fd, ev, ln);


// si l!=ln je m'enerve!!! Non mais il lirait des morceaux qd ca lui
chante?

for(
i=0;
i<ln/sizeof(struct inotify_event);
i+=ev[i].len/sizeof(struct inotify_event)+1;
)
{
// be a man, my son
}
}
C'est pur, non? Y'a juste un cast, et encore, je ne sais pas s'il est
vraiment necessaire.

Je me demande quand meme: dans mon vieux K&R (Comme dit Nico ;-) ) les
declarations doivent etre faites en premier...
Ca marcherait, ca?
T'en penses quoi?

Bon, ok y'a des divisions, mais sizeof(struct inotify_event) vaut 16,
donc un bon decalage et hop! gcc sait gerer ca, j'espere.

Zeyes :

Mais la longueur totale n'est pas fixe.
L'allocation doit etre refaite a chaque fois (m'enfin presque)
Alors je peux pas utiliser un type defini statique
C'est pour ça que je parlais de tableaux dynamiques. Si je ne me plante pas,

ça donne quelque chose comme :


while (...) {
poll(...);
ioctl(...);
union {char buf[ln]; struct inotify_event blah;} x;
read(jesaispluscommentsappelletonfd,x.buf,ln);
void * i; struct inotify_event * j;
for (i=x.buf,j=&x.blah;x!=(void *)x.buf+ln;
i+=sizeof(struct inotify_event)+j->len,j=i) {
// traiter l'évènement pointé par j
}
}

.
En fouillant dans inotify.c (ce qui est dit aussi dans inotify.txt, mais

j'ai -encore une fois- lu trop vite)
Le len est aligne pour coller a un tableau de inotify_event
Donc:
while (...)
{
poll(...);
ioctl(...,&ln);

inotify_event ev[ln/sizeof(struct inotify_event)];

l=read (fd, ev, ln);


// si l!=ln je m'enerve!!! Non mais il lirait des morceaux qd ca lui
chante?

for(
i=0;
i<ln/sizeof(struct inotify_event);
i+=ev[i].len/sizeof(struct inotify_event)+1;
)
{
// be a man, my son
}
}
C'est pur, non? Y'a juste un cast, et encore, je ne sais pas s'il est
vraiment necessaire.

Je me demande quand meme: dans mon vieux K&R (Comme dit Nico ;-) ) les
declarations doivent etre faites en premier...
Ca marcherait, ca?
T'en penses quoi?

Bon, ok y'a des divisions, mais sizeof(struct inotify_event) vaut 16,
donc un bon decalage et hop! gcc sait gerer ca, j'espere.
Oups... le caste est:

l=read (fd, (char*) ev, ln);

Zeyes :

En fouillant dans inotify.c (ce qui est dit aussi dans inotify.txt, mais
j'ai -encore une fois- lu trop vite)
Le len est aligne pour coller a un tableau de inotify_event

Dans la page de man, je lis :

The name field is only present when an event is returned for a
file inside a watched directory; it identifies the file pathname
relative to the watched directory. This pathname is null-terminated,
and may include further null bytes to align subsequent reads to a
suitable address boundary.

Pour moi, ça veut juste dire qu'il y a le padding qu'il faut pour qu'on
puisse mettre un inotify_event juste après, pas que la taille du name soit
un multiple de la taille d'un inotify_event.

// si l!=ln je m'enerve!!! Non mais il lirait des morceaux qd ca lui
chante?

Bein on était bien tombé sur un cas où l valait 0. Il faut toujours
vérifier.

Je me demande quand meme: dans mon vieux K&R (Comme dit Nico ;-) ) les
declarations doivent etre faites en premier...

Oui, historiquement, il fallait. En C99, ce n'est plus nécessaire.

Ca marcherait, ca?
T'en penses quoi?

Je ne suis pas persuadé que ça soit bon, pour la raison indiquée ci-dessus.
Pourquoi tu ne veux pas prendre le code que j'ai mis dans un cousin de ce
message?

Bon, ok y'a des divisions, mais sizeof(struct inotify_event) vaut 16,
donc un bon decalage et hop! gcc sait gerer ca, j'espere.

Oui, j'imagine. À ce sujet :

http://david.monniaux.free.fr/dotclear/index.php/2006/12/13/55-p2-p1-ou-pourquoi-il-est-utile-de-savoir-calculer-dans-z-2bz

Desole pour le temps de reponse:
freeze kernel->scandisk->reboot->scabdisk....
L'interet de 20doz: ca rend l'humain tolerable aux pannes..
;-)

Zeyes :

En fouillant dans inotify.c (ce qui est dit aussi dans inotify.txt, mais
j'ai -encore une fois- lu trop vite)
Le len est aligne pour coller a un tableau de inotify_event

Dans la page de man, je lis :

The name field is only present when an event is returned for a
file inside a watched directory; it identifies the file pathname
relative to the watched directory. This pathname is null-terminated,
and may include further null bytes to align subsequent reads to a
suitable address boundary.

Pour moi, ça veut juste dire qu'il y a le padding qu'il faut pour qu'on
puisse mettre un inotify_event juste après, pas que la taille du name soit
un multiple de la taille d'un inotify_event.
Extrait du inotify.c:

/*
* We need to pad the filename so as to properly align an
* array of inotify_event structures. Because the structure is
* small and the common case is a small filename, we just round
* up to the next multiple of the structure's sizeof. This is
* simple and safe for all architectures.
*/

// si l!=ln je m'enerve!!! Non mais il lirait des morceaux qd ca lui
chante?

Bein on était bien tombé sur un cas où l valait 0. Il faut toujours
vérifier.
Voui, ca m'enerve! Dans ce cas ou il ne lit pas des morceaux!

Je veriefierai, ok mais amha, on ne recupere que des morceaux entiers.

Je me demande quand meme: dans mon vieux K&R (Comme dit Nico ;-) ) les
declarations doivent etre faites en premier...

Oui, historiquement, il fallait. En C99, ce n'est plus nécessaire.
Ah... je me pretendais dinosoresque.......

Ca marcherait, ca?
T'en penses quoi?

Je ne suis pas persuadé que ça soit bon, pour la raison indiquée ci-dessus.
Pourquoi tu ne veux pas prendre le code que j'ai mis dans un cousin de ce
message?
Voui je l'ai marque, mais y'avais deux variables locales... et je me dis

que les developpeurs de inotify ne se sont pas enquiquines pour rien...
parce que c'est explicite dans le code!

Bon, ok y'a des divisions, mais sizeof(struct inotify_event) vaut 16,
donc un bon decalage et hop! gcc sait gerer ca, j'espere.

Oui, j'imagine. À ce sujet :

http://david.monniaux.free.fr/dotclear/index.php/2006/12/13/55-p2-p1-ou-pourquoi-il-est-utile-de-savoir-calculer-dans-z-2bz
Ah... je vais voir.... e

Et aussi, quel plaisir de contrarier Nicolas Georges!
Mais la, ca n'a rien a faire ici!