applied a fix for this in the render branch, will merge to trunk in a day or 2. http://markmail.org/message/awnbh2zzdivks657
On Mon, Mar 29, 2010 at 4:11 PM, Jochen Schmitt <[email protected]> wrote: > Am 29.03.2010 11:43, schrieb Rob M: >> Hi, >> >> The patch is bad style. You should not pass literal sizes to strncpy - what >> happens when someone changes the size of the array? >> Passing sizeof(files[num].owner) is better (but doesn't allow easy >> translation from 8bit chars to wide chars). >> Would it not also be better to increase the size of the owner field as well >> as not overflowing the array? >> >> > Thank you for your feedback. You have right that I should use > sizeof(...) instead > of a literal constant to get more flexible for the case when the > definition of > the owner member may been changed. > > For an increasement of the owner field, it may be necessary to know a > maximum > length which an userid may have. Unfportunately, I doesn't know any > limitation for it. > > At last as far as I know the getpwent() function only returns 8bit data, > so a discussion > of translation to 16bit char is more theoratical, because in this case > we have to call > a special function to do this translation. > > An inproved version of the patch you may find at the end of this mail. > > Best Regards: > > Jochen Schmitt > > diff -up blender/source/blender/blenlib/intern/storage.c.uid > blender/source/blender/blenlib/intern/storage.c > --- blender/source/blender/blenlib/intern/storage.c.uid 2010-03-28 > 19:18:49.511022187 +0200 > +++ blender/source/blender/blenlib/intern/storage.c 2010-03-29 > 15:51:00.164136396 +0200 > @@ -331,7 +331,8 @@ void BLI_adddirstrings() > struct passwd *pwuser; > pwuser = getpwuid(files[num].s.st_uid); > if ( pwuser ) { > - strcpy(files[num].owner, pwuser->pw_name); > + strncpy(files[num].owner, pwuser->pw_name, > sizeof(files(num].owner)-1); > + files[num].owner[sizeof(files{num].owner)-1] = '\0'; > } else { > sprintf(files[num].owner, "%d", files[num].s.st_uid); > } > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
