4-bytes or 8-bytes alignment?

[mrby]

Hi,guys,

char s1[10] = "abcde";
char s2[3];
printf("%d",s1-s2);

What should be the result on a 32-bit machine? It is 8 on my machine,
why?

Here is the output of "uname -a" on my machine:
$uname -a
SunOS virgo 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-250

 

[Karthik Kumar]

Hi,guys,

char s1[10] = "abcde";
char s2[3];
printf("%d",s1-s2);

How are these two variables's1' and 's2' related and
why would you want to subtract them ?

What should be the result on a 32-bit machine? It is 8 on my machine,
why?

The starting address of where s1 is allocated is entirely independent
of where s2 is allocated and vice-versa. So it does not matter
what your machine is. For the same machine, a different implementation
can give a diff. answer.

 

[Jack Klein]

Hi,guys,

char s1[10] = "abcde";
char s2[3];
printf("%d",s1-s2);

Comparing pointers that are not part of the same object or array, or
one past the end of the same object or array, produces undefined
behavior.

What should be the result on a 32-bit machine?

There is no 'should', your program produces undefined behavior so the
C standard no longer places any requirements at all on what happens.

It is 8 on my machine,
why?

Since the behavior is undefined, there is no 'why' as far as C is
concerned.

Here is the output of "uname -a" on my machine:
$uname -a
SunOS virgo 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-250

What is 'uname' and why do we care what it outputs?

If you are questioning the alignment your compiler uses in defining
data objects, and there is no guarantee that the output of your code
has anything at all to do with that, then you are asking in the wrong
place.

Data alignment in C is not defined by the language, it is specifically
implementation-defined. That means it is up to the compiler provider
to do whatever it is they want to do. It may be based on the
architecture of the underlying hardware, it may be based on the kind
of car the head programmer drives, it may be based on the fact that
the compiler writer has stock in a memory chip company, and wants to
make sure that you need to buy lots of extra memory.

If you want to know what alignment your compiler uses and why, either
contact their technical support or ask in a group that supports your
compiler. It is not a language issue.

 

[Mike Wahler]

Hi,guys,

char s1[10] = "abcde";
char s2[3];
printf("%d",s1-s2);

What should be the result on a 32-bit machine?

It could be anything, or nothing at all. Attempting
to compute the difference between two addresses which
are not within the same object (or in the case of
any array, one element past its end) produces undefined behavior.

Also undefined is the your use of the %d printf() specifier
for an object not of type 'int'.

Also note that simply because your two array definitions
occur sequentially in your code, doesn't mean they will
be stored anywhere near each other in memory.

It is 8 on my machine,
why?

Just because. Tomorrow it might be 42.

Here is the output of "uname -a" on my machine:
$uname -a
SunOS virgo 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-250

Your machine doesn't matter. Here we discuss ISO standard C,
which is platform-neutral, and whose specification deems the
behavior of that code as undefined.

As far as alignment requirements which might be imposed by
your particular implementation and/or platform, you'll need
to consult your documentation. The C language doesn't control
that.


-Mike

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

Hi,guys,

char s1[10] = "abcde";
char s2[3];
printf("%d",s1-s2);

What should be the result on a 32-bit machine? It is 8 on my machine,
why?

Whatever the compiler thinks suitable,often influenced by hardware.

It might very well fail somehow also, as you invoke undefined behavior
with the above.

On most common machines with a flat memory layout you'll
get the diffrence in memory locations though.

The compiler/linker might decide reorder your 2 variables...

 

[pete]

Hi,guys,

char s1[10] = "abcde";
char s2[3];
printf("%d",s1-s2);

What should be the result on a 32-bit machine?

It could be anything, or nothing at all. Attempting
to compute the difference between two addresses which
are not within the same object (or in the case of
any array, one element past its end) produces undefined behavior.

Also undefined is the your use of the %d printf() specifier
for an object not of type 'int'.

s1-s2 is an expression of type ptrdiff_t.
There are no objects of type ptrdiff_t,
refered to in the above code.

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

Hi,guys,

char s1[10] = "abcde";
char s2[3];
printf("%d",s1-s2);

What should be the result on a 32-bit machine?

It could be anything, or nothing at all. Attempting
to compute the difference between two addresses which
are not within the same object (or in the case of
any array, one element past its end) produces undefined behavior.

Also undefined is the your use of the %d printf() specifier
for an object not of type 'int'.

s1-s2 is an expression of type ptrdiff_t.
There are no objects of type ptrdiff_t,
refered to in the above code.

Not really. Two pointers to compatible types may be subtracted
to yield ptrdiff_t, but is only valid for two pointers into the
same array, or one past it.

 

[Mike Wahler]

Hi,guys,

char s1[10] = "abcde";
char s2[3];
printf("%d",s1-s2);

What should be the result on a 32-bit machine?

It could be anything, or nothing at all. Attempting
to compute the difference between two addresses which
are not within the same object (or in the case of
any array, one element past its end) produces undefined behavior.

Also undefined is the your use of the %d printf() specifier
for an object not of type 'int'.

s1-s2 is an expression of type ptrdiff_t.
There are no objects of type ptrdiff_t,
refered to in the above code.

OK, make that "for a value not of type int".

All better now?

-Mike

 

[Mark McIntyre]

Hi,guys,

char s1[10] = "abcde";
char s2[3];
printf("%d",s1-s2);

What should be the result on a 32-bit machine?

absolutely anything.

It is 8 on my machine, why?

luck.

To explain more fully, there's nothing that requires adjacently declared
pointers to be stored adjacently, nor for any specific meaning to be given
to the difference between two arbitrary pointers.