From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-help-return-22829-listarch-gcc-help=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 5841 invoked by alias); 16 Feb 2006 14:57:45 -0000
Received: (qmail 5816 invoked by uid 22791); 16 Feb 2006 14:57:44 -0000
X-Spam-Check-By: sourceware.org
Received: from xproxy.gmail.com (HELO xproxy.gmail.com) (66.249.82.207)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 16 Feb 2006 14:57:42 +0000
Received: by xproxy.gmail.com with SMTP id s19so85399wxc         for <gcc-help@gcc.gnu.org>; Thu, 16 Feb 2006 06:57:40 -0800 (PST)
Received: by 10.70.109.11 with SMTP id h11mr548776wxc;         Thu, 16 Feb 2006 06:57:38 -0800 (PST)
Received: by 10.70.73.2 with HTTP; Thu, 16 Feb 2006 06:57:38 -0800 (PST)
Message-ID: <80f4f2b20602160657g33bbf1b1g9d810a2d5c2ab65c@mail.gmail.com>
Date: Thu, 16 Feb 2006 14:57:00 -0000
From: Jim Stapleton <stapleton.41@gmail.com>
To: gcc-help@gcc.gnu.org
Subject: quick question
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-IsSubscribed: yes
Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-help@gcc.gnu.org>
Sender: gcc-help-owner@gcc.gnu.org
X-SW-Source: 2006-02/txt/msg00116.txt.bz2

I remember reading that there are systems where they don't like basic
variables to be put on offsets that are not an integer multiple of the
variable size, up to variables the size of a system word.

example, if this applied to the 32 bit x86 architechture where a word
is defined as 4 bytes (I'm talking about the actual arch here, and not
the bastardized useage form 16bit ASM):
char [1 byte]: can be anywhere
short [2 bytes]: any 2N address, where N is an integer, and N > 0.
int/long [4 bytes]: any 4N address, where N is an integer, and N > 0
long long [8 bytes]: any 4N address, where N is an integer, and N > 0
(8 bytes > 1 word)


Now, this set of code works on the x86 platform, but I'm worried it
may not work on other platforms, am I correct in this worry?

#include <stdio.h>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
int main()
{
  char test[] =3D  {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
0x08, 0x09, 0x0a};
  char *tptr =3D test;
  int *ptr;

  ptr =3D (int*)tptr;
  printf("tptr[0]: %x\n", *ptr);

  tptr++;
  ptr =3D (int*)tptr;
  printf("tptr[1]: %x\n", *ptr);

  tptr++;
  ptr =3D (int*)tptr;
  printf("tptr[2]: %x\n", *ptr);

  tptr++;
  ptr =3D (int*)tptr;
  printf("tptr[3]: %x\n", *ptr);

  return 0;
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

output (note: all my machines are 32 bit x86, so this output is
correct for them, on reasonable endian machines, the bytes in the
output would be reversed):
tptr[0]: 3020100
tptr[1]: 4030201
tptr[2]: 5040302
tptr[3]: 6050403



Thanks
-Jim