[Bf-committers] Possible uninitialized code error in init_structDNA()

Brecht Van Lommel brechtvanlommel at pandora.be
Sun Oct 7 02:23:14 CEST 2012


We assume "int" to be 32 bits on both 32bit and 64bit platforms. This
is the case for windows and unix systems:
http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models

There are some platforms that do not follow this convention, but
they're pretty esoteric. There's probably lots of code in Blender that
would break in this case.

Brecht.

On Mon, Oct 1, 2012 at 2:16 AM, Chad Fraleigh <chadf at triularity.org> wrote:
> While looking at init_structDNA() in
> source/blender/makesdna/intern/dna_genfile.c (line 316 in v2.63a), I
> noticed these fragments of code:
>
>         int *data, *verg, gravity_fix= -1;
>
>         char str[8], *cp;
>
>         verg= (int *)str;
>         data= (int *)sdna->data;
>
>         strcpy(str, "SDNA");
>         if ( *data == *verg ) {
>
>
> I must assume that 'str' is declared as char[8] to hold space for
> either a 32-bit or 64-bit integer, which 'verg' is then cast as later.
> A string of 4 characters is then copied into it to initialize the
> array, after which it's value is compared through out the function. So
> if run on a 32-bit system, everything is fine.. but on a 64-bit system
> there could be problems. Since 'str' is allocated on the stack it's
> contents are by default undefined/random. The strcpy() will fill in
> the first 5 bytes (4 letters and the null), but the last 3 bytes will
> still be potential junk. This would imply that any 64-bit int compares
> would be unreliable.
>
> So am I missing something here, or is the compiler _always_ being
> forced to zero-initialize stack data using some switch, that would
> make this code not really a problem, ever (and I'm just being
> paranoid)? If it is a potential issue, then 'str' should be
> pre-initialized with memset(str, 0, 8); or something equivalent for
> the last 3 bytes.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers


More information about the Bf-committers mailing list