Simple allocation of two buffer on AMD64

[jimenezrick]

- Code compiled by GCC:

int main(void)
{
char a[] = "123";
char b[] = "abc";

printf("%p %p\n", a, b);

return 0;
}

- Running it on AMD64 gives me:

0x7fff929c9410 0x7fff929c9400

- What is the reason for 16 bytes of distance between two address and
not just 8 bytes?

 

[Eric Sosman]

- Code compiled by GCC:

int main(void)
{
char a[] = "123";
char b[] = "abc";

printf("%p %p\n", a, b);

return 0;
}

- Running it on AMD64 gives me:

0x7fff929c9410 0x7fff929c9400

- What is the reason for 16 bytes of distance between two address and
not just 8 bytes?

Ask the gcc implementors. It was they who decided how
the compiler should allocate space, not the C language itself.
C does not require a sixteen-byte separation, but does not
forbid it.

 

[santosh]

- Code compiled by GCC:

int main(void)
{
char a[] = "123";
char b[] = "abc";

printf("%p %p\n", a, b);

Cast 'a' and 'b' to void *.

return 0;
}

- Running it on AMD64 gives me:

0x7fff929c9410 0x7fff929c9400

- What is the reason for 16 bytes of distance between two address and
not just 8 bytes?

It's an implementation detail that Standard C says nothing about. It may
be due to alignment reasons.

 

[jimenezrick]

It's an implementation detail that Standard C says nothing about. It may

be due to alignment reasons.

I know. Just curiosity about the election of 16 bytes over 8 (what I
expected).

Thanks anyway.

 

[Justin Spahr-Summers]

char a[] = "123";
char b[] = "abc";

printf("%p %p\n", a, b);

Cast 'a' and 'b' to void *.

Correct me if I'm wrong, but isn't this technically a case where it
shouldn't matter, seeing as char * and void * have the exact same
representation?

 

[Richard Tobin]

char a[] = "123";
char b[] = "abc";

printf("%p %p\n", a, b);

Cast 'a' and 'b' to void *.

[/QUOTE]

Correct me if I'm wrong, but isn't this technically a case where it
shouldn't matter, seeing as char * and void * have the exact same
representation?

We discussed this a few weeks ago. The idea seems to be that although
they have the same representation, they aren't necessarily passed to
variadic functions in the same way.

-- Richard

 

[jimenezrick]

Cast 'a' and 'b' to void *.

Same result.

Correct me if I'm wrong, but isn't this technically a case where it
shouldn't matter, seeing as char * and void * have the exact same
representation?

Yes, in this case is similar.

 

[CBFalconer]

- Code compiled by GCC:

int main(void) {
char a[] = "123";
char b[] = "abc";

printf("%p %p\n", a, b);
return 0;
}

- Running it on AMD64 gives me:

0x7fff929c9410 0x7fff929c9400

- What is the reason for 16 bytes of distance between two address
and not just 8 bytes?

Many systems access memory in 128 bit chunks. Aligning objects to
this value prevents having to do two memory accesses, when one
suffices. Check the gcc docs for means of avoiding this if
desired.

 

[Martin Ambuhl]

- Code compiled by GCC:

int main(void)
{
char a[] = "123";
char b[] = "abc";

printf("%p %p\n", a, b);

return 0;
}

- Running it on AMD64 gives me:

0x7fff929c9410 0x7fff929c9400

- What is the reason for 16 bytes of distance between two address and
not just 8 bytes?

That is, of course, an issue between your hardware, your OS, and the
version of gcc you are using. There is no reason, as far as C is
concerned, for the addresses of two distinct objects to have any
particular relationship. But your post is extremely amusing. The fact
that you think it somehow appropriate for the difference to be eight
when sizeof a and sizeof b are each four is hilarious.

You really should include <stdio.h> when using the variadic function printf.
Even with the special relationship between the form of (void *) and
(char *), you should cast pointers to (void *) when using the "%p"
specifier, since that is what it signals.

 

[CBFalconer]

.... snip ...

Date:
Fri, 02 Nov 2007 00:43:31 +0100

Your clock is mis-set.

 

[Doug]

- Code compiled by GCC:

int main(void)
{
char a[] = "123";
char b[] = "abc";

printf("%p %p\n", a, b);

return 0;
}

- Running it on AMD64 gives me:

But your post is extremely amusing. The fact
that you think it somehow appropriate for the difference to be eight
when sizeof a and sizeof b are each four is hilarious.

You don't get out enough.

Aside from that, it would have probably been more helpful to explain
why, rather than just laughing.

To the OP, the definition of char 'a[] = "123;"' causes the compiler
to allocate space for exactly 4 characters (pedant point: or more, but
only 4 are 'legally' accessible by the code). Using sizeof on an
array is one of those cases where the array name doesn't degenerate to
a pointer to its first element - so 'sizeof a' will return 4
(characters) not sizeof (char *). (I think you probably expected 8
because the size of a pointer on your system is 8, and you expected
the compiler to emit two pointers in your stack frame.)

Of course, this isn't actually that relevant to your question - as
others have pointed out, the standard says nothing about how the
compiler has to layout locals in a stack frame (or even that it has to
use a stack), and Jacob has probably nailed why it ends up being 16
with your platform.

Doug

 

[Richard]

... snip ...

Date:
Fri, 02 Nov 2007 00:43:31 +0100

Your clock is mis-set.

And you are posting with two signatures. Still.

 

[Martin Ambuhl]

- Code compiled by GCC:
int main(void)
{
char a[] = "123";
char b[] = "abc";
printf("%p %p\n", a, b);
return 0;
}
- Running it on AMD64 gives me:

But your post is extremely amusing. The fact
that you think it somehow appropriate for the difference to be eight
when sizeof a and sizeof b are each four is hilarious.

You don't get out enough.

That is uncalled for, irrelevant, and stupidly rude.

Aside from that, it would have probably been more helpful to explain
why, rather than just laughing.

If you had read what you snipped, you would know better than that. If
you snip away explanations, of course they disappear. From the
standpoint of the C programming language, everything you wrote after
this line is off-topic and superfluous. As was your childish crap above.

 

[Stephen Sprunk]

And you are posting with two signatures. Still.

Like me, the post leaves his machine with a single signature. The second
one is added by our news server. If your client were designed correctly, it
would strip off both signatures when replying since the first, not last,
occurrence of "-- " denotes the start of the signature block. Technically,
it's all one overlong signature with a spurious "-- " in the middle.

S

 

[jacob navia]

- Code compiled by GCC:

int main(void)
{
char a[] = "123";
char b[] = "abc";

printf("%p %p\n", a, b);

return 0;
}

- Running it on AMD64 gives me:

0x7fff929c9410 0x7fff929c9400

- What is the reason for 16 bytes of distance between two address and
not just 8 bytes?

The stack MUST be aligned to an 8 byte boundary in
64 bits AMD/Intel. If that fails, each access provokes
a misaligned read, what makes performance take a
big hit.

Access to XMM registers in most cases MUST be aligned to a
16 byte boundary. If not, you can't load the 16 byte
XMM registers quickly.

Some compilers decide that performance is better than
wasting memory in the alignment, and align all variables
in the stack to a 16 byte boundary even when it is not
needed, as in your example.

Other compilers will say that performance by loading the XMM
registers is lost when the cache hits go down because the
program uses more memory and will NOT align to a 16 byte
boundary but only to a 8 byte boundary what is bad enough.

 

[Jack Klein]

char a[] = "123";
char b[] = "abc";

printf("%p %p\n", a, b);

Cast 'a' and 'b' to void *.

Correct me if I'm wrong, but isn't this technically a case where it
shouldn't matter, seeing as char * and void * have the exact same
representation?

Yes and no. It doesn't matter, they are compatible in this case, but
not because they have the same representation.

Pointer to void and pointer to any of the three character types are
required to have the same size and representation, but nowhere does
the C standard that they be passed to functions in the same manner, in
the absence of a prototype.

The relevant definition on representation is 6.2.5 p26, first
sentence:

"A pointer to void shall have the same representation and alignment
requirements as a pointer to a character type.39)"

Where the "39)" is a reference to footnote 39, on the same page:

"39) The same representation and alignment requirements are meant to
imply interchangeability as arguments to functions, return values from
functions, and members of unions."

My reading of this is that implementations are strongly urged, but not
required, to make them compatible in all of these situations. It is a
quality of implementation whether they are or not.

But in the particular case of an argument to *printf() to match a "%p"
conversion specifier, compatibility is guaranteed by specific wording
in the standard by 6.5.2.2 p6.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Richard]

Like me, the post leaves his machine with a single signature. The
second one is added by our news server. If your client were designed

Which is why you should either leave off the second signature OR move to
another news service which does not attach another one.

correctly, it would strip off both signatures when replying since the
first, not last, occurrence of "-- " denotes the start of the
signature block. Technically, it's all one overlong signature with a
spurious "-- " in the middle.

Incorrect from what i can gather. The proper way is to clip the
last. otherwise it is possible that embedded text could be cut.

Both gnus and slrn suffer and I can't be bothered to manually snip since
he, and now you, are the ONLY two people who feel that posting with two
signatures is in anyway ok or justified.

It's just a question of common decency and trying to keep usenet a civil
place. Normally I wouldn't worry too much but since 4 out of 5 of
Falconer's posts criticise the way other people post it is an issue. As
someone said - he is a hypocrite.

 

[santosh]

Like me, the post leaves his machine with a single signature. The
second
one is added by our news server. If your client were designed
correctly, it would strip off both signatures when replying

As does KNode for example.

since the first, not last,
occurrence of "-- " denotes the start of the signature block.
Technically, it's all one overlong signature with a spurious "-- " in
the middle.

I agree.

 

[Richard Tobin]

"39) The same representation and alignment requirements are meant to
imply interchangeability as arguments to functions, return values from
functions, and members of unions."

My reading of this is that implementations are strongly urged, but not
required, to make them compatible in all of these situations. It is a
quality of implementation whether they are or not.

My reading is that they had not considered the possibility of
different argument passing conventions when they wrote that text. If
they had, they should have been explicit about it.

-- Richard

 

[Richard Bos]

Like me, the post leaves his machine with a single signature. The second
one is added by our news server.

And like for him, that is a piss-poor excuse for you. You _know_ your
server does that. You should take it into account when writing your
posts.

Richard