Hello, in the trunk's documentation
http://gcc.gnu.org/onlinedocs/gccint/GTY-Options.html I am reading:


> variable_size
>         The type machinery expects the types to be of constant size.
>         When this is not true, for example, with structs that have
>         array fields or unions, the type machinery cannot tell how
>         many bytes need to be allocated at each allocation. The
>         variable_size is used to mark such types. The type machinery
>         then provides allocators that take a parameter indicating an
>         exact size of object being allocated. 
>         
>         For example, 
>         
>         struct GTY((variable_size)) sorted_fields_type {
>                     int len;
>                     tree GTY((length ("%h.len"))) elts[1];
>                   };
>              
>         
>         Then the objects of struct sorted_fields_type are allocated in
>         GC memory as follows: 
>         
>         field_vec = ggc_alloc_sorted_fields_type (size);


I find the last paragraph and example very misleading, but perhaps I am not a 
native english speaker and am understanding wrongly.

I would much prefer a sentence like 

  The type machinery then provides allocators that take a parameter indicating 
an exact size of object being allocated (like malloc does)

and the exemple should better be


 Then the objects of struct sorted_fields_type are allocated in GC memory as 
follows, assuming n is the number of elements: 

         field_vec = ggc_alloc_sorted_fields_type (sizeof(sorted_fields_type) + 
(n-1) * sizeof(tree));

 The factor is n-1 (not n) since the struct sorted_fields_type is declared with 
an array elts[1]


By the way, I would very much like that GCC code would assume that 
variable-sized struct-ures are permitted, and declare instead
        struct GTY((variable_size)) sorted_fields_type {
                    int len;
                    tree GTY((length ("%h.len"))) elts[];  
                };

Perhaps such a transition is needed, or at least very useful, even before any 
transition to C++ ?

Cheers.

P.S. I am not yet proposing a gty.texi patch, because I have still a one-line 
patch to it awaiting approval
 http://gcc.gnu.org//ml/gcc-patches/2010-07/msg00744.html and I usually don't 
work on patching files for which I have patches awaiting review.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
        

Reply via email to