Tcl Source Code

Inspired by bug #3127687, noted that on 64-bit
platforms, where sizeof(integer) == 8, some structures
are over-allocated because sizeof() might count
additional padding bytes. That's no big deal, except
that it is strange anyway to use [4] as the number
of bytes in the structure.

Solution: use the TclOffset macro to calculate the
right size, in stead of substracting two sizeof()'s. That
will correctly take padding bytes into account.

patch attached

backported strcpy->memcpy changes to 8.5 and 8.4 as well, not any other struct change

File Added - 395809: 3129448_2.patch

Part 2, a few more places where the same pattern was used. Patch attached.

Here is a small test program (try it on any UNIX machine) which shows the
dirrerence between substracting two sizes or determining the offset.

This program prints:
    12 8

Here I used a long long as data type in stead of an int. It will occur
on any machine where sizeof(int) = 8.

=====================================================
#include <stdio.h>
#define TclOffset(type, field) \
((int) ((char *) &((type *) 0)->field))
typedef struct {
long long dummy;
char buf[4];
} mytype;
void main() {
mytype x;
int answer1 = sizeof(x) - sizeof(x.buf);
int answer2 = (unsigned)TclOffset(mytype, buf);
printf("%d %d\n", answer1, answer2);
}

Hmmm... the actual patch applies doesn't
appear to have anything to do with integers,
but with pointer sizes and alignment matters.

Is there a platform on which the effectiveness
of the patch is actually tested?

what does "integer" mean in this report?  int ? long int ?

allow_comments - 1

Fixed in HEAD

don't bother for Tcl 8.5 and lower

File Added - 395354: 3129448.patch