Michael Hunter wrote: > 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_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? > The other solution is to make the default always be sorted, which would require that the objects in the files always be written in that order (http://defect.opensolaris.org/bz/show_bug.cgi?id=9012#c5). This makes the implementation even more complex as each write (and maybe the nvlist also) be sorted. The flag gives consumers of libnwam the control over how they want the objects to be walked. This RFE is adding to the functionality that exists, not replacing it. If the consensus is that the walk be sorted without actually changing the ordering in the files, then the flag is not necessary. Anurag
