🚀 go-pugleaf

Pierre Habouzit wrote:

Merci pour l'explication, je crois avoir compris jusqu'ici.

> mais du coup, vu que je ne peux garantir que scratch coincide avec la
> deuxi�me case du tablea __bufs, je me suis r�sign� � avoir comme type
> pour mes messages :
> 
> struct message {
>     [ ... pleins de choses dont pas mal de 'headers' ...];

Je ne comprends plus � partir d'ici.

>     struct {
>         const blob_t *original;
>         blob_t *scratch;
>     };

Pourquoi garder la structure au dessus, et -peut-�tre suis-je mal
r�veill�- comment y acc�der sans la nommer ?

>     blob_t *__bufs[2];
> 
>     [ ... encore pleins de choses ...];
> };
> 
> ce qui me force � maintenir l'invariant __bufs[0] == original et
> __bufs[1]==scratch � la main, mais vu que ces pointeurs changent peu,
> c'est pas trop g�nant pour moi, et autant je ne voulais pas perdre la
> taille d'un pointeur en plus dans mes headers vu que j'en ai beaucoup
> et que j'avais d�j� des champs de bits, mais perdre 16 octets dans la
> structure de message n'est pas trop g�nant. (enfin 16 ou plutot
> sizof(blob_t*)*2)

Ou 8 suivant la taille du pointeur.
Mais je n'en vois pas l'inter�t.

Pourquoi cela au-dessous ne suffirait-il pas ? :

struct message {
    [ ... pleins de choses dont pas mal de 'headers' ...];
    blob_t *__bufs[2];
    [ ... encore pleins de choses ...];
};

d'autant que la valeur du bit modified est l'indice du blob_t * et que
son nom est judicieusement choisi, �tant � 0 lorsque le blob_t n'est
pas modifi�.

De plus, je ne vois pas l'int�r�t d'�loigner le bit modified du tableau
de pointeurs en le mettant dans un (ou des) header, puisque le fait que
le buffer soit modifi� semble d�pendre du message et non de ces
headers.
Mais je n'ai peut-�tre pas tout compris.

Je me sers assez peu des unions, seulement lorsque des choses qui n'ont
a priori pas grand chose � voir entre elles peuvent occuper un m�me
espace du fait qu'elles ne peuvent �tre pr�sentes en m�me temps.