standard memory allocator alignment issue...

**Chris Thomasson** · Jun 27 '08, 07:36 PM

Re: standard memory allocator alignment issue...

"Chris Thomasson" <cristom@comcas t.netwrote in message
news:5umdnWjfo9 PPQrrVnZ2dnUVZ_ rLinZ2d@comcast .com...

How many C compilers provide extensions which allow for a standard
implementation of the following hack?

[...]

Standard in the sense of being portable within the various versions of a
given vendors C compiler...

:^o

**Eric Sosman** · Jun 27 '08, 07:36 PM

Re: standard memory allocator alignment issue...

Chris Thomasson wrote:

How many C compilers provide extensions which allow for a standard
implementation of the following hack?
_______________ _______________ _______________ _______________ ________
#include <stdio.h>
>
>
typedef union aligner_types_u aligner_types;
typedef struct aligner_offset_ s aligner_offset;
>
>
union aligner_types_u {
char char_;
short s_l;
int i_;
long l_;
double d_;
long double ld_;
float f_;
void *p_;
char (*fp0_) (char);
long double (*fp1_) (char, long double);
union aligner_types* uap_;
/* long long ll_; */
/* [...] */
};
>
>
struct aligner_offset_ s {
char offset;
aligner_types types;
};
>
>
#define ALIGN_MAX ( \
sizeof(aligner_ offset) sizeof(aligner_ types) \
? sizeof(aligner_ offset) - sizeof(aligner_ types) \
: sizeof(aligner_ types) \
)
>
>
int main() {
printf("ALIGN_M AX == %d\n\nhit enter to exit...\n", ALIGN_MAX);
getchar();
return 0;
}
>
_______________ _______________ _______________ _______________ ________
>
>
>
Thanks...
>
>
>
BTW, the ALIGN_MAX macro is needed because using a sizeof(aligner_ types)
alone is not sufficient... How many people are running platforms where
(ALIGN_MAX == 8) is true?

Observation #1: It is impossible that the "else" branch
of ALIGN_MAX' expansion will be evaluated, so you might as
well just put `42' there.

Observation #2: ALIGN_MAX computes the number of bytes
in the struct, minus one for the `char' element, minus the
number of padding bytes before the union, minus the number
of padding bytes *after* the union. I've never seen a
compiler where that final term would be non-zero, but ...

Observation #3: On some platforms the program will say
"ALIGN_MAX == 0", because that's one of the likely outcomes
of the undefined behavior in the printf() call.

Observation #4: I'm not entirely sure, but I think the
"extension" you seek is the offsetof macro in <stddef.h>.

--
Eric Sosman
esosman@ieee-dot-org.invalid

**Chris Thomasson** · Jun 27 '08, 07:36 PM

Re: standard memory allocator alignment issue...

"Eric Sosman" <esosman@ieee-dot-org.invalidwrot e in message
news:0f-dnYX0zdkuqbXVnZ 2dnUVZ_qTinZ2d@ comcast.com...

Chris Thomasson wrote:

>How many C compilers provide extensions which allow for a standard
>implementati on of the following hack?
>______________ _______________ _______________ _______________ _________

[...]

>______________ _______________ _______________ _______________ _________

[...]

>BTW, the ALIGN_MAX macro is needed because using a sizeof(aligner_ types)
>alone is not sufficient... How many people are running platforms where
>(ALIGN_MAX == 8) is true?

>
Observation #1: It is impossible that the "else" branch
of ALIGN_MAX' expansion will be evaluated, so you might as
well just put `42' there.

Observation #2: ALIGN_MAX computes the number of bytes
in the struct, minus one for the `char' element, minus the
number of padding bytes before the union, minus the number
of padding bytes *after* the union. I've never seen a
compiler where that final term would be non-zero, but ...

Observation #3: On some platforms the program will say
"ALIGN_MAX == 0", because that's one of the likely outcomes
of the undefined behavior in the printf() call.

Totally agree with everything you said. As for printf, at least I should
have it formatted for an unsigned integer: %u. ;^(

Observation #4: I'm not entirely sure, but I think the
"extension" you seek is the offsetof macro in <stddef.h>.

You got it:
_______________ _______________ _______________ _______________ _______
#include <stdio.h>
#include <stddef.h>

typedef union aligner_types_u aligner_types;
typedef struct aligner_offset_ s aligner_offset;

union aligner_types_u {
char char_; short s_l; int i_; long l_;
double d_; long double ld_; float f_;
union aligner_types* uap_;
void *p_; char (*fp0_) (char);
long double (*fp1_) (char, long double);
/* long long ll_; */
/* [...] */
};

struct aligner_offset_ s {
char offset;
aligner_types types;
};

#define ALIGN_MAX offsetof(aligne r_offset, types)

int main() {
printf("ALIGN_M AX == %u\n\nhit enter to exit...\n", ALIGN_MAX);
getchar();
return 0;
}
_______________ _______________ _______________ _______________ _______

I am trying to come up with somewhat "portable" hack that can attempt to
determine maximum alignment for integral types across a number of different
compilers.

**Chris Thomasson** · Jun 27 '08, 07:37 PM

Re: standard memory allocator alignment issue...

"Chris Thomasson" <cristom@comcas t.netwrote in message
news:tf-dndgJDOpIJbXVnZ 2dnUVZ_hOdnZ2d@ comcast.com...

"Eric Sosman" <esosman@ieee-dot-org.invalidwrot e in message
news:0f-dnYX0zdkuqbXVnZ 2dnUVZ_qTinZ2d@ comcast.com...

>Chris Thomasson wrote:

>>How many C compilers provide extensions which allow for a standard
>>implementatio n of the following hack?
>>_____________ _______________ _______________ _______________ __________

[...]

>>_____________ _______________ _______________ _______________ __________

[...]

> Observation #4: I'm not entirely sure, but I think the
>"extension" you seek is the offsetof macro in <stddef.h>.

>
You got it:
_______________ _______________ _______________ _______________ _______

[...]

_______________ _______________ _______________ _______________ _______

I am trying to come up with somewhat "portable" hack that can attempt to
determine maximum alignment for integral types across a number of
different compilers.

I have been successfully using the previous method in several
general-purpose memory allocators. However, I wanted to see if there is a
better way; offsetof works fine. BTW, does anybody know why there is not
something like ALIGN_MAX in <limits.halread y?

**Eric Sosman** · Jun 27 '08, 07:37 PM

Re: standard memory allocator alignment issue...

Chris Thomasson wrote:

[... determining alignment with a struct and offsetof ...]
>
I have been successfully using the previous method in several
general-purpose memory allocators. However, I wanted to see if there is
a better way; offsetof works fine. BTW, does anybody know why there is
not something like ALIGN_MAX in <limits.halread y?

The Rationale doesn't say why not. My guess (and it's only
a guess) is that the Committee didn't want to get too involved
in specifying exactly how pointers convert to and from integers.
Without knowledge of which integer bits have what significance,
you can't make effective use of things like ALIGN_MAX.

--
Eric.Sosman@sun .com

**Chris Thomasson** · Jun 27 '08, 07:37 PM

Re: standard memory allocator alignment issue...

"Eric Sosman" <Eric.Sosman@su n.comwrote in message
news:1210630927 .374478@news1nw k...

Chris Thomasson wrote:

>[... determining alignment with a struct and offsetof ...]
>>
>I have been successfully using the previous method in several
>general-purpose memory allocators. However, I wanted to see if there is a
>better way; offsetof works fine. BTW, does anybody know why there is not
>something like ALIGN_MAX in <limits.halread y?

>
The Rationale doesn't say why not. My guess (and it's only
a guess) is that the Committee didn't want to get too involved
in specifying exactly how pointers convert to and from integers.
Without knowledge of which integer bits have what significance,
you can't make effective use of things like ALIGN_MAX.

Humm, a compiler vendor already has to supply a malloc implementation which
returns an address that is aligned on a sufficient boundary for all integral
types; right? Well, IMVHO, the standard could mention that a vendor shall
set the value of ALIGN_MAX to a sufficient boundary analogous to the
non-NULL return value of malloc which can accompany the alignment of any
integral type. The rational is that a vendor can likely extract ALIGN_MAX
from their existing malloc implementation. ..

Is that total crap?

;^)

**Spiros Bousbouras** · Jun 27 '08, 07:37 PM

Re: standard memory allocator alignment issue...

On 12 May, 23:41, "Chris Thomasson" <cris...@comcas t.netwrote:

"Eric Sosman" <Eric.Sos...@su n.comwrote in message
>
news:1210630927 .374478@news1nw k...
>

Chris Thomasson wrote:

[... determining alignment with a struct and offsetof ...]

>

I have been successfully using the previous method in several
general-purpose memory allocators. However, I wanted to see if there is a
better way; offsetof works fine. BTW, does anybody know why there is not
something like ALIGN_MAX in <limits.halread y?

>

The Rationale doesn't say why not. My guess (and it's only
a guess) is that the Committee didn't want to get too involved
in specifying exactly how pointers convert to and from integers.
Without knowledge of which integer bits have what significance,
you can't make effective use of things like ALIGN_MAX.

>
Humm, a compiler vendor already has to supply a malloc implementation which
returns an address that is aligned on a sufficient boundary for all integral
types; right? Well, IMVHO, the standard could mention that a vendor shall
set the value of ALIGN_MAX to a sufficient boundary analogous to the
non-NULL return value of malloc which can accompany the alignment of any
integral type. The rational is that a vendor can likely extract ALIGN_MAX
from their existing malloc implementation. ..

If you had ALIGN_MAX what would you do with it ?

**Richard Tobin** · Jun 27 '08, 07:37 PM

Re: standard memory allocator alignment issue...

In article <c2857956-f78b-47c9-97a9-a262af5535f6@r6 6g2000hsg.googl egroups.com>,
Spiros Bousbouras <spibou@gmail.c omwrote:

>If you had ALIGN_MAX what would you do with it ?

Write an allocator that returns memory adequately aligned for any
object, perhaps.

-- Richard
--
:wq

**Keith Thompson** · Jun 27 '08, 07:37 PM

Re: standard memory allocator alignment issue...

Spiros Bousbouras <spibou@gmail.c omwrites:

On 12 May, 23:41, "Chris Thomasson" <cris...@comcas t.netwrote:

>"Eric Sosman" <Eric.Sos...@su n.comwrote in message
>>
>news:121063092 7.374478@news1n wk...
>>

Chris Thomasson wrote:
>[... determining alignment with a struct and offsetof ...]

>>

>I have been successfully using the previous method in several
>general-purpose memory allocators. However, I wanted to see if there is a
>better way; offsetof works fine. BTW, does anybody know why there is not
>something like ALIGN_MAX in <limits.halread y?

>>

The Rationale doesn't say why not. My guess (and it's only
a guess) is that the Committee didn't want to get too involved
in specifying exactly how pointers convert to and from integers.
Without knowledge of which integer bits have what significance,
you can't make effective use of things like ALIGN_MAX.

>>
>Humm, a compiler vendor already has to supply a malloc implementation which
>returns an address that is aligned on a sufficient boundary for all integral
>types; right? Well, IMVHO, the standard could mention that a vendor shall
>set the value of ALIGN_MAX to a sufficient boundary analogous to the
>non-NULL return value of malloc which can accompany the alignment of any
>integral type. The rational is that a vendor can likely extract ALIGN_MAX
>from their existing malloc implementation. ..

>
If you had ALIGN_MAX what would you do with it ?

One thing I might do is write my own memory allocator. Call malloc()
once to get a big chunk of memory (guaranteed to be aligned properly),
then dole out properly-aligned subchunks of it in response to
my_malloc() calls. Free everything at once by free()ing the big
chunk. Without ALIGN_MAX, I can't think of a portable way to
guarantee that the pointers returned by my_malloc are properly
aligned.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

**Ian Collins** · Jun 27 '08, 07:37 PM

Re: standard memory allocator alignment issue...

Chris Thomasson wrote:

"Eric Sosman" <Eric.Sosman@su n.comwrote in message
news:1210630927 .374478@news1nw k...

>Chris Thomasson wrote:

>>[... determining alignment with a struct and offsetof ...]
>>>
>>I have been successfully using the previous method in several
>>general-purpose memory allocators. However, I wanted to see if there
>>is a better way; offsetof works fine. BTW, does anybody know why
>>there is not something like ALIGN_MAX in <limits.halread y?

>>
> The Rationale doesn't say why not. My guess (and it's only
>a guess) is that the Committee didn't want to get too involved
>in specifying exactly how pointers convert to and from integers.
>Without knowledge of which integer bits have what significance,
>you can't make effective use of things like ALIGN_MAX.

>
Humm, a compiler vendor already has to supply a malloc implementation
which returns an address that is aligned on a sufficient boundary for
all integral types; right? Well, IMVHO, the standard could mention that
a vendor shall set the value of ALIGN_MAX to a sufficient boundary
analogous to the non-NULL return value of malloc which can accompany the
alignment of any integral type. The rational is that a vendor can likely
extract ALIGN_MAX from their existing malloc implementation. ..
>
Is that total crap?
>

That depends on whether the compiler supplies its own runtime, or uses
one supplied by the host environment.

--
Ian Collins.

**Ian Collins** · Jun 27 '08, 07:37 PM

Re: standard memory allocator alignment issue...

Chris Thomasson wrote:

"Eric Sosman" <esosman@ieee-dot-org.invalidwrot e in message
news:0f-dnYX0zdkuqbXVnZ 2dnUVZ_qTinZ2d@ comcast.com...

>Chris Thomasson wrote:

>>How many C compilers provide extensions which allow for a standard
>>implementatio n of the following hack?
>>_____________ _______________ _______________ _______________ __________

[...]

>>_____________ _______________ _______________ _______________ __________

[...]

>>BTW, the ALIGN_MAX macro is needed because using a
>>sizeof(aligne r_types) alone is not sufficient... How many people are
>>running platforms where (ALIGN_MAX == 8) is true?

>>
> Observation #1: It is impossible that the "else" branch
>of ALIGN_MAX' expansion will be evaluated, so you might as
>well just put `42' there.

>

> Observation #2: ALIGN_MAX computes the number of bytes
>in the struct, minus one for the `char' element, minus the
>number of padding bytes before the union, minus the number
>of padding bytes *after* the union. I've never seen a
>compiler where that final term would be non-zero, but ...

>

> Observation #3: On some platforms the program will say
>"ALIGN_MAX == 0", because that's one of the likely outcomes
>of the undefined behavior in the printf() call.

>
Totally agree with everything you said. As for printf, at least I should
have it formatted for an unsigned integer: %u. ;^(
>
>
>

> Observation #4: I'm not entirely sure, but I think the
>"extension" you seek is the offsetof macro in <stddef.h>.

>
You got it:
_______________ _______________ _______________ _______________ _______
#include <stdio.h>
#include <stddef.h>
>
>
typedef union aligner_types_u aligner_types;
typedef struct aligner_offset_ s aligner_offset;
>
>
union aligner_types_u {
char char_; short s_l; int i_; long l_;
double d_; long double ld_; float f_;
union aligner_types* uap_;
void *p_; char (*fp0_) (char);
long double (*fp1_) (char, long double);
/* long long ll_; */
/* [...] */
};
>
>
struct aligner_offset_ s {
char offset;
aligner_types types;
};
>
>
#define ALIGN_MAX offsetof(aligne r_offset, types)
>
>
int main() {
printf("ALIGN_M AX == %u\n\nhit enter to exit...\n", ALIGN_MAX);
getchar();
return 0;
}
_______________ _______________ _______________ _______________ _______
>
>
>
I am trying to come up with somewhat "portable" hack that can attempt to
determine maximum alignment for integral types across a number of
different compilers.
>

How would this code with the situation where sizeof(long long) == 8 and
sizeof(long double) = 12? In that case, 16 would probably be a sensible
value for ALIGN_MAX. Not easy to calculate as a compile time constant.

--
Ian Collins.

**Chris Thomasson** · Jun 27 '08, 07:37 PM

Re: standard memory allocator alignment issue...

"Ian Collins" <ian-news@hotmail.co mwrote in message
news:68s1qcF2um j15U2@mid.indiv idual.net...

Chris Thomasson wrote:

>"Eric Sosman" <Eric.Sosman@su n.comwrote in message
>news:121063092 7.374478@news1n wk...

>>Chris Thomasson wrote:
>>>[... determining alignment with a struct and offsetof ...]
>>>>
>>>I have been successfully using the previous method in several
>>>general-purpose memory allocators. However, I wanted to see if there
>>>is a better way; offsetof works fine. BTW, does anybody know why
>>>there is not something like ALIGN_MAX in <limits.halread y?
>>>
>> The Rationale doesn't say why not. My guess (and it's only
>>a guess) is that the Committee didn't want to get too involved
>>in specifying exactly how pointers convert to and from integers.
>>Without knowledge of which integer bits have what significance,
>>you can't make effective use of things like ALIGN_MAX.

>>
>Humm, a compiler vendor already has to supply a malloc implementation
>which returns an address that is aligned on a sufficient boundary for
>all integral types; right? Well, IMVHO, the standard could mention that
>a vendor shall set the value of ALIGN_MAX to a sufficient boundary
>analogous to the non-NULL return value of malloc which can accompany the
>alignment of any integral type. The rational is that a vendor can likely
>extract ALIGN_MAX from their existing malloc implementation. ..
>>
>Is that total crap?
>>

That depends on whether the compiler supplies its own runtime, or uses
one supplied by the host environment.

Humm, good point indeed. Well, in that case, I guess the compiler can
probably make use of the ALIGN_MAX definition already residing in the
<limits.hfile provided by a "conforming " host environment, where
conforming means provides a version of the next standard which would include
ALIGN_MAX in <limits.h>).. .

**Chris Thomasson** · Jun 27 '08, 07:37 PM

Re: standard memory allocator alignment issue...

"Ian Collins" <ian-news@hotmail.co mwrote in message
news:68s2caF2um j15U3@mid.indiv idual.net...

Chris Thomasson wrote:

>"Eric Sosman" <esosman@ieee-dot-org.invalidwrot e in message
>news:0f-dnYX0zdkuqbXVnZ 2dnUVZ_qTinZ2d@ comcast.com...

>>Chris Thomasson wrote:

[...]

>______________ _______________ _______________ _______________ ________

>>
>I am trying to come up with somewhat "portable" hack that can attempt to
>determine maximum alignment for integral types across a number of
>different compilers.
>>

How would this code with the situation where sizeof(long long) == 8 and
sizeof(long double) = 12? In that case, 16 would probably be a sensible
value for ALIGN_MAX. Not easy to calculate as a compile time constant.

On GCC for 32-bit x86 windows, sizeof(double) == 8, sizeof(long double) ==
12 and the offsetof version of ALIGN_MAX is 8. I think reasoning for result
is that 4 is suitable alignment for long double and 8 is already compatible
with boundary of 4.

**Ian Collins** · Jun 27 '08, 07:37 PM

Re: standard memory allocator alignment issue...

Chris Thomasson wrote:

"Ian Collins" <ian-news@hotmail.co mwrote in message
news:68s2caF2um j15U3@mid.indiv idual.net...

>Chris Thomasson wrote:

>>"Eric Sosman" <esosman@ieee-dot-org.invalidwrot e in message
>>news:0f-dnYX0zdkuqbXVnZ 2dnUVZ_qTinZ2d@ comcast.com...
>>>Chris Thomasson wrote:

[...]

>>_____________ _______________ _______________ _______________ _________

>

>>>
>>I am trying to come up with somewhat "portable" hack that can attempt to
>>determine maximum alignment for integral types across a number of
>>different compilers.
>>>

>How would this code with the situation where sizeof(long long) == 8 and
>sizeof(long double) = 12? In that case, 16 would probably be a sensible
>value for ALIGN_MAX. Not easy to calculate as a compile time constant.

>
On GCC for 32-bit x86 windows, sizeof(double) == 8, sizeof(long double)
== 12 and the offsetof version of ALIGN_MAX is 8. I think reasoning for
result is that 4 is suitable alignment for long double and 8 is already
compatible with boundary of 4.

Fair enough. I have used 16 for several "semi-portable" allocators. On
each platform where these were used, the native malloc also used 16.

--
Ian Collins.

standard memory allocator alignment issue...

standard memory allocator alignment issue...

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment