468,545 Members | 1,891 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,545 developers. It's quick & easy.

How to make local variable's address is 8 byte alignment?

HP-UX 11.23, HP aC++ B3910B A.03.63

Here is a samples.

bjhp1 /nfs/users/pjia>cat tt.c
#include <stdlib.h>

int main()
{
int i =10 ;
char p[1024] ="" ;

printf("%p, %p\n", &i, p) ;
return 0 ;
}

bjhp1 /nfs/users/pjia>aCC +DD64 tt.c

bjhp1 /nfs/users/pjia>./a.out
800003ffbfff0f78, 800003ffbfff0f7c

I hope the pointer p's address is 800003ffbfff0f80, not
800003ffbfff0f7c
Is there any option to realize this?
Jan 10 '08 #1
15 3912
Pengjun Jia wrote:
HP-UX 11.23, HP aC++ B3910B A.03.63

Here is a samples.

bjhp1 /nfs/users/pjia>cat tt.c
#include <stdlib.h>

int main()
{
int i =10 ;
char p[1024] ="" ;

printf("%p, %p\n", &i, p) ;
return 0 ;
}

bjhp1 /nfs/users/pjia>aCC +DD64 tt.c

bjhp1 /nfs/users/pjia>./a.out
800003ffbfff0f78, 800003ffbfff0f7c

I hope the pointer p's address is 800003ffbfff0f80, not
800003ffbfff0f7c
Why is this important to you?
Is there any option to realize this?
This is specific to your platform, I'd think, so asking in a
platform-specific group would be more appropriate.

In general, I think you'd need to try playing tricks with embedding "p"
in a union (or possibly a structure) to force alignment.

For example, you may find that something like :-

union {
double for_alignment;
char p[1024];
} fudge.

Would get aligned at an 8-byte boundary.

But I repeat this is platform-specific, so YMMV...
Jan 10 '08 #2
Pengjun Jia wrote:
>
HP-UX 11.23, HP aC++ B3910B A.03.63

Here is a samples.

bjhp1 /nfs/users/pjia>cat tt.c
#include <stdlib.h>

int main()
{
int i =10 ;
char p[1024] ="" ;

printf("%p, %p\n", &i, p) ;
return 0 ;
}

bjhp1 /nfs/users/pjia>aCC +DD64 tt.c

bjhp1 /nfs/users/pjia>./a.out
800003ffbfff0f78, 800003ffbfff0f7c

I hope the pointer p's address is 800003ffbfff0f80, not
800003ffbfff0f7c
Is there any option to realize this?
/* BEGIN eight_bytes.c */

#include <stdio.h>

#define BYTES 8
#define NUM 256

int main(void)
{
int i[NUM + BYTES / sizeof(int)] = {10};
char *p = BYTES + (char *)i ;

printf("%p, %p\n", (void *)i, (void *)p) ;
return 0 ;
}

/* END eight_bytes.c */

--
pete
Jan 10 '08 #3
pete wrote, On 10/01/08 11:42:
Pengjun Jia wrote:
>HP-UX 11.23, HP aC++ B3910B A.03.63

Here is a samples.

bjhp1 /nfs/users/pjia>cat tt.c
#include <stdlib.h>

int main()
{
int i =10 ;
char p[1024] ="" ;

printf("%p, %p\n", &i, p) ;
return 0 ;
}

bjhp1 /nfs/users/pjia>aCC +DD64 tt.c

bjhp1 /nfs/users/pjia>./a.out
800003ffbfff0f78, 800003ffbfff0f7c

I hope the pointer p's address is 800003ffbfff0f80, not
800003ffbfff0f7c
Is there any option to realize this?

/* BEGIN eight_bytes.c */

#include <stdio.h>

#define BYTES 8
#define NUM 256

int main(void)
{
int i[NUM + BYTES / sizeof(int)] = {10};
You have change the type of i which is likely to be a problem. You have
also failed to note that this may well *not* do what is wanted as the C
language does not guarantee how things will be arranged in memory. For
instance some compiler start playing clever tricks with where arrays are
placed on the stack and/or put "guard values" either side of arrays to
detect buffer overflows and/or try and detect when they have occurred.
char *p = BYTES + (char *)i ;

printf("%p, %p\n", (void *)i, (void *)p) ;
It would have been helpful if you had told the OP why you added the
casts. The reason being that %p specifically requires a void* pointer
and other pointer types can have different sizes, representations or
passing mechanisms.
return 0 ;
}

/* END eight_bytes.c */
--
Flash Gordon
Jan 10 '08 #4
Pengjun Jia wrote:
HP-UX 11.23, HP aC++ B3910B A.03.63

Here is a samples.

bjhp1 /nfs/users/pjia>cat tt.c
#include <stdlib.h>

int main()
{
int i =10 ;
char p[1024] ="" ;

printf("%p, %p\n", &i, p) ;
return 0 ;
}
Well, you could always allocate an extra 8 bytes for the array p
and then use a pointer to the first position in that array which is on
an 8 byte alignment instead of p itself.

I don't see the point though for this example. With integers and such
it will likely make a difference if the variable is not properly
aligned, but the compiler will generally take care of that for you.

Regards,

David Mathog
Jan 10 '08 #5
David Mathog wrote:
Pengjun Jia wrote:
>HP-UX 11.23, HP aC++ B3910B A.03.63

Here is a samples.

bjhp1 /nfs/users/pjia>cat tt.c
#include <stdlib.h>

int main()
{
int i =10 ;
char p[1024] ="" ;

printf("%p, %p\n", &i, p) ;
return 0 ;
}

Well, you could always allocate an extra 8 bytes for the array p
and then use a pointer to the first position in that array which is on
an 8 byte alignment instead of p itself.

I don't see the point though for this example. With integers and such
it will likely make a difference if the variable is not properly
aligned, but the compiler will generally take care of that for you.
If the OP wanted to use a general area of bytes as a place he could take
a pointer into and manipulate as (for example) long or double, he may
need this sort of guarantee. Perhaps he'll tell us what he's trying to
do...
Jan 10 '08 #6
Pengjun Jia wrote:
HP-UX 11.23, HP aC++ B3910B A.03.63

Here is a samples.

bjhp1 /nfs/users/pjia>cat tt.c
#include <stdlib.h>

int main()
{
int i =10 ;
char p[1024] ="" ;

printf("%p, %p\n", &i, p) ;
return 0 ;
}

bjhp1 /nfs/users/pjia>aCC +DD64 tt.c

bjhp1 /nfs/users/pjia>./a.out
800003ffbfff0f78, 800003ffbfff0f7c

I hope the pointer p's address is 800003ffbfff0f80, not
800003ffbfff0f7c
Is there any option to realize this?
Of course, the other approach is to malloc the space rather than using
automatic storage, as malloc() must return a block of memory
appropriately aligned for any kind of data, which implies the strictest
alignment constraint.
Jan 10 '08 #7
Flash Gordon wrote:
>
pete wrote, On 10/01/08 11:42:
Pengjun Jia wrote:
HP-UX 11.23, HP aC++ B3910B A.03.63

Here is a samples.

bjhp1 /nfs/users/pjia>cat tt.c
#include <stdlib.h>

int main()
{
int i =10 ;
char p[1024] ="" ;

printf("%p, %p\n", &i, p) ;
return 0 ;
}

bjhp1 /nfs/users/pjia>aCC +DD64 tt.c

bjhp1 /nfs/users/pjia>./a.out
800003ffbfff0f78, 800003ffbfff0f7c

I hope the pointer p's address is 800003ffbfff0f80, not
800003ffbfff0f7c
Is there any option to realize this?
/* BEGIN eight_bytes.c */

#include <stdio.h>

#define BYTES 8
#define NUM 256

int main(void)
{
int i[NUM + BYTES / sizeof(int)] = {10};

You have change the type of i which is likely to be a problem.
Yes.
You have also failed to note that this may well *not* do what is
wanted as the C language does not guarantee how things will be
arranged in memory.
For instance some compiler start playing clever tricks with
where arrays are
placed on the stack and/or put "guard values" either side of arrays to
detect buffer overflows and/or try and detect when they have occurred.
char *p = BYTES + (char *)i ;
The C language guarantees this much for this case:
1 p is 8 bytes after i
2 p[0] through p[256 * sizeof(int) - 1] may be accessed

This line would have been better though:

int i[(1024 + BYTES) / sizeof(int)] = {10};

then it would have been p[0] through p[1023].

--
pete
Jan 11 '08 #8
On Thu, 10 Jan 2008 03:09:51 -0800 (PST), Pengjun Jia
<ji********@gmail.comwrote in comp.lang.c:
HP-UX 11.23, HP aC++ B3910B A.03.63

Here is a samples.

bjhp1 /nfs/users/pjia>cat tt.c
#include <stdlib.h>

int main()
{
int i =10 ;
char p[1024] ="" ;

printf("%p, %p\n", &i, p) ;
return 0 ;
}

bjhp1 /nfs/users/pjia>aCC +DD64 tt.c

bjhp1 /nfs/users/pjia>./a.out
800003ffbfff0f78, 800003ffbfff0f7c

I hope the pointer p's address is 800003ffbfff0f80, not
800003ffbfff0f7c
Is there any option to realize this?
There is no valid or invalid option to align the "pointer p's address"
because 'p' is not, and never will be,a pointer.

--
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
Jan 11 '08 #9
On Thu, 10 Jan 2008 16:46:30 +0000, Mark Bluemel
<ma**********@pobox.comwrote in comp.lang.c:
David Mathog wrote:
Pengjun Jia wrote:
HP-UX 11.23, HP aC++ B3910B A.03.63

Here is a samples.

bjhp1 /nfs/users/pjia>cat tt.c
#include <stdlib.h>

int main()
{
int i =10 ;
char p[1024] ="" ;

printf("%p, %p\n", &i, p) ;
return 0 ;
}
Well, you could always allocate an extra 8 bytes for the array p
and then use a pointer to the first position in that array which is on
an 8 byte alignment instead of p itself.

I don't see the point though for this example. With integers and such
it will likely make a difference if the variable is not properly
aligned, but the compiler will generally take care of that for you.

If the OP wanted to use a general area of bytes as a place he could take
a pointer into and manipulate as (for example) long or double, he may
need this sort of guarantee. Perhaps he'll tell us what he's trying to
do...
No, he can't want to do that, it would produce undefined behavior.
Look up "declared type" in the standard. Since 'p' is defined as an
array of char, accessing it as objects type double or long is
undefined.

--
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
Jan 11 '08 #10
Yes, you are right. In later code I have a sentence like this : if
(*((long *) p) == 10000) ; { ... }
So I have to make sure p is 4 alignment (32-bit) and 8 alignment (64-
bit).
On 1月11日, 上午12时46分, Mark Bluemel <mark_blue...@pobox.comwrote:
David Mathog wrote:
If the OP wanted to use a general area of bytes as a place he could take
a pointer into and manipulate as (for example) long or double, he may
need this sort of guarantee. Perhaps he'll tell us what he's trying to
do...
Jan 14 '08 #11
Pengjun Jia wrote: (Top-posting corrected
Mark Bluemel <mark_blue...@pobox.comwrote:
>If the OP wanted to use a general area of bytes as a place he could take
a pointer into and manipulate as (for example) long or double, he may
need this sort of guarantee. Perhaps he'll tell us what he's trying to
do...

Yes, you are right. In later code I have a sentence like this : if
(*((long *) p) == 10000) ; { ... }
So I have to make sure p is 4 alignment (32-bit) and 8 alignment (64-
bit).
I thought that must be it.

As I've already said, you need to either
a) use malloc() to get your memory
(that is guaranteed to be correctly aligned and usable for any
data type)
or
b) use a union to force alignment.
(I'm not convinced that this is actually guaranteed to work by
the standard, but in practice, I'm sure it will on most "normal"
hosted C implementations.)
Jan 14 '08 #12
Mark Bluemel wrote:
Pengjun Jia wrote: (Top-posting corrected
....
>Yes, you are right. In later code I have a sentence like this : if
(*((long *) p) == 10000) ; { ... }
So I have to make sure p is 4 alignment (32-bit) and 8 alignment (64-
bit).
....
b) use a union to force alignment.
(I'm not convinced that this is actually guaranteed to work by
the standard, but in practice, I'm sure it will on most "normal"
hosted C implementations.)
How could an implementation of C meet the requirements for how unions
work if one of the union members was misaligned for its type?
Jan 14 '08 #13
James Kuyper wrote:
Mark Bluemel wrote:
>Pengjun Jia wrote: (Top-posting corrected
...
>>Yes, you are right. In later code I have a sentence like this : if
(*((long *) p) == 10000) ; { ... }
So I have to make sure p is 4 alignment (32-bit) and 8 alignment (64-
bit).
...
> b) use a union to force alignment.
(I'm not convinced that this is actually guaranteed to work by
the standard, but in practice, I'm sure it will on most "normal"
hosted C implementations.)

How could an implementation of C meet the requirements for how unions
work if one of the union members was misaligned for its type?
My concern is whether Jack Klein's comment "Since 'p' is defined as
an array of char, accessing it as objects type double or long is
undefined" was justified...

In Pengjun's position, I'd be using malloc(), I think.
Jan 14 '08 #14
Mark Bluemel wrote:
James Kuyper wrote:
>Mark Bluemel wrote:
....
>> b) use a union to force alignment.
(I'm not convinced that this is actually guaranteed to work by
the standard, but in practice, I'm sure it will on most "normal"
hosted C implementations.)
How could an implementation of C meet the requirements for how unions
work if one of the union members was misaligned for its type?

My concern is whether Jack Klein's comment "Since 'p' is defined as
an array of char, accessing it as objects type double or long is
undefined" was justified...
I presumed that you were referring to replacing p with a object of a
union type that contained both double and long members. That avoids the
problem that Jack Klein was talking about, at least if the union is used
correctly: never read from a member of one type if the last write was to
a member of the other type.

Jan 14 '08 #15
Mark Bluemel wrote:
>
Pengjun Jia wrote: (Top-posting corrected
Mark Bluemel <mark_blue...@pobox.comwrote:
If the OP wanted to use a general area
of bytes as a place he could take
a pointer into and manipulate as (for example) long or double,
he may
need this sort of guarantee.
Perhaps he'll tell us what he's trying to
do...
Yes, you are right. In later code I have a sentence like this : if
(*((long *) p) == 10000) ; { ... }
So I have to make sure p is 4 alignment
(32-bit) and 8 alignment (64-bit).

I thought that must be it.

As I've already said, you need to either
a) use malloc() to get your memory
(that is guaranteed to be correctly aligned and usable for any
data type)
or
b) use a union to force alignment.
(I'm not convinced that this is actually guaranteed to work by
the standard, but in practice, I'm sure it will on most "normal"
hosted C implementations.)
The simplest way to acheive alignment and sufficient memory,
is to declare the whole array as being an array of type long,
and then point p, which is a (char *), at one of the members.

--
pete
Jan 14 '08 #16

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Shashi | last post: by
8 posts views Thread by Groups User | last post: by
11 posts views Thread by Taran | last post: by
2 posts views Thread by Avi Laviad | last post: by
6 posts views Thread by scottyman | last post: by
Facultas
6 posts views Thread by Facultas | last post: by
11 posts views Thread by !truth | last post: by
1 post views Thread by UniDue | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.