[Bf-committers] [PATCH] Patch to storage.c to avoid crash on long userids

Jochen Schmitt Jochen at herr-schmitt.de
Mon Mar 29 16:11:17 CEST 2010

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
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.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,
+              files[num].owner[sizeof(files{num].owner)-1] = '\0';
             } else {
                 sprintf(files[num].owner, "%d", files[num].s.st_uid);

More information about the Bf-committers mailing list