On Mon, Aug 21, 2006 at 02:31:18PM -0400, Alan Stern wrote: > I assumed the point of those optimizations was obvious enough not to need > any comment. Bad assumption. When you say "This is what the patch does", then I assume the whole patch does that. When you say "The patch does X, and by the way, does some other minor cleanups", then I know the bits which make no sense are the cleanups and not needed for X. > (It is still present according to the web interface to the > scsi-misc repository on www.kernel.org, BTW.) It's not ... http://git.kernel.org/git/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=blob;h=a24d3461fc788b797f492cfff333fa419e9f3bc3;hb=d2afb3ae04e36dbc6e9eb2d8bd54406ff7b6b3bd;f=drivers/scsi/scsi_scan.c I took it out with: http://git.kernel.org/git/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=4ff36718ede26ee2da73f2dae94d71e2b06845fc > Besides, let's assume you're right and the vendor really did mean to > terminate the string by putting a NUL there. The bytes following the > NUL could be anything, but most likely the vendor would set them to more > NULs or to spaces. So the patch would change those NULs to spaces, and > the result is you end up with exactly the string the vendor intended, > except now it is padded with spaces to the correct length as required by > the spec. My suggestion produced the same result as yours for these cases. > On the other hand, if some of the characters following the NUL happen to > be printable then the patch does change the meaning of the string. That's > inevitable; when vendors don't follow the rules then sometimes they will > be misunderstood. Who's to say whether the pre-patch interpretation is > any better than the post-patch interpretation? I say so. I gave an example where my algorithm produces better results than yours in my response to Philip Auld. Do you have an example where yours gives preferable results? - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
