Hi Cyril, Cyril Plisko píše v út 18. 08. 2009 v 22:31 +0300: > On Tue, Aug 18, 2009 at 6:14 PM, Cyril Plisko<[email protected]> > wrote: > > On Thu, Nov 27, 2008 at 9:33 AM, Cyril Plisko<[email protected]> > > wrote: > >> On Thu, Nov 27, 2008 at 12:30 AM, Peter Buckingham > >> <[email protected]> wrote: > >>> Cyril Plisko wrote: > >>>> > >>>> 6777065 COMSTAR sources should be cstyle clean > >>>> 6777077 COMSTAR drivers unnecessary NUL-terminate strings > >>>> 6777085 COMSTAR Makefiles can take advantage of being ON citizens > >>> > >>> Cool! Can you request a sponsor too? We'll work on getting someone > >>> internal > >>> to take the ball from there. > >> > > > > After almost a year I finally found some time to get back this CRs. > > > > I updated the fix to the current ON code and want people to review them. > > The webrev is here - http://cr.opensolaris.org/~imp/comstar-fixes3/ > > I was asked privately about the inconsistency in the use of > INFO_BUF_SIZE in discovery.c and other places. > > Here is the story behind it. > > usr/src/uts/common/io/comstar/port/fct/discovery.c does not have > INFO_BUF_SIZE and INFO_BUF_SIZE_DOUBLE as its brethren, but rather > only have INFO_BUF_SIZE. > > Original file has one place where 80 bytes long buffer and some other > places with 160 bytes long buffers. Unfortunately this single > occurrence of 80 bytes buffer was not enough to hold the string that > snprintf() is trying to put in. So I decided to have only 160 bytes > buffers across all the discovery.c > > While original code doesn't constitute a serious issue (the message > would be cut, but no harm will be done) I think it is better to fix > it. > > I also felt that having INFO_BUF_SIZE_DOUBLE w/o INFO_BUF_SIZE would > be a little bit strange, so decided to drop _DOUBLE in this file. > Admittedly it creates dissimilarity with respect to the other files > [while saving us about a hundred bytes of code ;)] >
OK, thank you for explanation. No more comments :-) Best regards, Milan _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
