On Sun, 26 May 2013 22:20:58 -0500
Michael Roth mdr...@linux.vnet.ibm.com wrote:
With the introduction of native list types, we now have types such as
int64List where the 'value' field is not a pointer, but the actual
64-bit value.
On 32-bit architectures, this can lead to situations where
On Wed, May 29, 2013 at 01:32:52PM -0400, Luiz Capitulino wrote:
On Sun, 26 May 2013 22:20:58 -0500
Michael Roth mdr...@linux.vnet.ibm.com wrote:
With the introduction of native list types, we now have types such as
int64List where the 'value' field is not a pointer, but the actual
On Wed, 29 May 2013 13:12:18 -0500
mdroth mdr...@linux.vnet.ibm.com wrote:
On Wed, May 29, 2013 at 01:32:52PM -0400, Luiz Capitulino wrote:
On Sun, 26 May 2013 22:20:58 -0500
Michael Roth mdr...@linux.vnet.ibm.com wrote:
With the introduction of native list types, we now have types
On Mon, May 27, 2013 at 06:38:35AM +0200, Stefan Weil wrote:
Am 27.05.2013 05:20, schrieb Michael Roth:
With the introduction of native list types, we now have types such as
int64List where the 'value' field is not a pointer, but the actual
64-bit value.
On 32-bit architectures, this
With the introduction of native list types, we now have types such as
int64List where the 'value' field is not a pointer, but the actual
64-bit value.
On 32-bit architectures, this can lead to situations where 'next' field
offset in GenericList does not correspond to the 'next' field in the
types
Am 27.05.2013 05:20, schrieb Michael Roth:
With the introduction of native list types, we now have types such as
int64List where the 'value' field is not a pointer, but the actual
64-bit value.
On 32-bit architectures, this can lead to situations where 'next' field
offset in GenericList does
