On Tue, 01 Dec 2009 15:43:27 -0500
"Anurag S. Maskey" <Anurag.Maskey at Sun.COM> wrote:
[...]
> > nwamadm.c:848,nwamcfg.c:2988 Why create a variable which only holds this
> > constant?
> >
> purely cosmetic. I didn't like "FLAG_1 | FLAG_2" wrapping two lines. I
> can use the actual flag rather than the variable if it is confusing.
At least make it 'const int64' or whatever it was.
>
> > libnwam.h:95,99 What does having NWAM_FLAG_WLAN_WALK_PRIORITY_ORDER and
> > NWAM_FLAG_WALK_ALPHA_ORDER in the same flag set mean?
> >
> For Known WLANs, this should be an error. Only one of these walk flags
> should be used. For the other objects, nwam_valid_flags() will return
> failure if _WALK_PRIORITY_ORDER is given. I updated webrev for
> libnwam_known_wlan.c:nwam_walk_known_wlans() to make sure that only one
> of these flags is specified.
ACCEPT, but...
>
> > libnwam_ncp.c:522-523 Would something break if you just always sorted
> > the objects? Does anything assume some order in the walk? If not then
> > why even have the flag? Just always sort.
> >
> Nothing would break if the objects were always sorted. But they are not
> stored that way in the conf file and thus the flag to sort them. For
> ncp-*.conf files, the default order is as returned by readdir(3C).
> There is not always the need to do a sorted walk. For example, for
> "destroy -a" all objects are walked and it is not necessary to do a
> sorted walk.
So the introduced complexity of two code paths gains us ...?
Code reliability goes as the number of lines (and even more strongly as
the number of decision points). Here we've introduced lines of code
_and_ branches. What can we balance that against?
Michael
>
> Anurag
>
