change to acl_read module for supporting dirsync module

[Matthias Dieter Wallnöfer]

Hi ekacnet,

your points are perfectly valid. I only wanted to make you aware of this 
since using types correctly in the first place saves plenty of 
corrective and possibly time-consuming patching afterwards. First you 
might have to perform quite some manual lookups in the header files but 
by the time you get a good heuristic which structures are handled by 
which types.

I've also had some interesting discussions with Jelmer about wrong 
variable typing and also he suggested me that I should raise my concern 
to relevant patches. Indifferently, it is simply much nicer to have 
everything typed correctly and consistently.

Cheers,
Matthias

Matthieu Patou wrote:
> On 09/03/2011 12:08, Matthias Dieter Wallnöfer wrote:
>>    * I've also performed a quick review of the control implementation
>>      and I've noticed some type problems:
>>          o The counter variables aren't appropriate yet. LDB objects
>>            are counted as "unsigned int". That means the following in
>>            the downto manner: for (i >= ...num_values - 1; i !=
>>            (unsigned) - 1; i--).
>>          o On "for (i=0; i < rmd.ctr.ctr1.count; i++) {" "i" should be
>>            "uint32_t" since we are working os DSR stuff.
>>          o "functional_level" in "struct dirsync_control" should be
>>            typed as "int".
>>          o "addedAttributes" I would type as "unsigned int" (the same
>>            as "num_elements" in LDB).
> Mathias, thanks for the "review" that I didn't ask for but I didn't 
> made the review for myself, I just pushed in my tree for 3 reasons:
>
> * have a kind of remote backup
> * be able to discuss with nadya on this control
> * allow other to play with it
>
> For the moment it's in the state where "it works" but I'm fully aware 
> that the code is not 100% clean ...
>
> Matthieu.