Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #138077 > unrolled thread

Pointer conversion and alignment

Back to article view | Back to comp.lang.c

Contents

  Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-17 14:38 +0300
    Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-17 17:37 +0300
      Re: Pointer conversion and alignment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-17 21:01 +0000
        Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 00:43 +0300
          Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 01:20 +0300
            Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-17 18:12 -0500
              Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 02:32 +0300
                Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-17 18:59 -0500
                  Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 12:40 +0300
          Re: Pointer conversion and alignment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-18 02:14 +0000
            Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 13:23 +0300
              Re: Pointer conversion and alignment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-18 11:28 +0000
                Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 15:31 +0300
                  Re: Pointer conversion and alignment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-18 15:03 +0000
                    Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 23:00 +0300
        Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 00:49 +0300
    Re: Pointer conversion and alignment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-17 06:52 -0800
      Re: Pointer conversion and alignment Ian Collins <ian-news@hotmail.com> - 2018-11-18 09:18 +1300
        Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-11-17 13:49 -0800
          Re: Pointer conversion and alignment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-17 13:57 -0800
            Re: Pointer conversion and alignment Ian Collins <ian-news@hotmail.com> - 2018-11-18 11:08 +1300
              Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 01:13 +0300
                Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-11-17 18:37 -0800
          Re: Pointer conversion and alignment Philipp Klaus Krause <pkk@spth.de> - 2018-11-18 14:14 +0100
    Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-17 10:05 -0500
      Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 01:08 +0300
        Re: Pointer conversion and alignment "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-11-17 14:31 -0800
          Re: Pointer conversion and alignment "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-11-17 16:10 -0800
            Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-18 15:01 +0300
              Re: Pointer conversion and alignment James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-18 07:25 -0500
                Re: Pointer conversion and alignment "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-11-19 21:30 -0800
              Re: Pointer conversion and alignment "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-11-20 14:20 -0800
        Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-17 18:04 -0500
        Re: Pointer conversion and alignment Philipp Klaus Krause <pkk@spth.de> - 2018-11-18 14:18 +0100
        Re: Pointer conversion and alignment scott@slp53.sl.home (Scott Lurndal) - 2018-11-18 19:49 +0000
      Re: Pointer conversion and alignment Tim Rentsch <txr@alumni.caltech.edu> - 2018-11-23 18:27 -0800
        Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-23 21:59 -0500
          Re: Pointer conversion and alignment Tim Rentsch <txr@alumni.caltech.edu> - 2018-11-24 00:32 -0800
            Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-24 08:17 -0500
              Re: Pointer conversion and alignment Tim Rentsch <txr@alumni.caltech.edu> - 2018-11-29 09:55 -0800
                Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-29 21:48 -0500
                  Re: Pointer conversion and alignment Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-05 04:14 -0800
                    Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-12-05 08:14 -0500
                      Re: Pointer conversion and alignment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-05 05:29 -0800
                        Re: Pointer conversion and alignment David Brown <david.brown@hesbynett.no> - 2018-12-05 14:44 +0100
                        Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-12-05 21:58 -0500
                      Re: Pointer conversion and alignment Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-12-05 16:38 +0300
                      Re: Pointer conversion and alignment scott@slp53.sl.home (Scott Lurndal) - 2018-12-05 14:23 +0000
                      Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-12-05 14:35 -0800
                      Re: Pointer conversion and alignment Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-08 19:28 -0800
                        Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-12-09 08:18 -0500
                          Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-12-09 14:35 -0500
                            Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-12-09 14:04 -0800
                              Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-12-09 20:40 -0500
                                Re: Pointer conversion and alignment Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-17 07:18 -0800
                                  Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-12-17 12:35 -0800
                                    Re: Pointer conversion and alignment Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-17 12:48 -0800
        Re: Pointer conversion and alignment "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-11-24 18:33 -0800
    My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-19 02:26 +0300
      Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-19 11:08 +0000
        Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-19 15:37 +0300
          Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-19 15:39 +0300
            Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-19 15:07 +0000
              Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-19 22:24 +0300
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jameskuyper@alumni.caltech.edu - 2018-11-19 12:33 -0800
                  Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-20 00:34 +0300
                    Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jameskuyper@alumni.caltech.edu - 2018-11-19 14:38 -0800
                      Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-20 00:43 +0000
                        Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-19 21:44 -0500
                        Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jadill33@gmail.com - 2018-11-20 07:11 -0800
                          Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] bart4858@gmail.com - 2018-11-20 10:02 -0800
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-19 22:20 +0000
                  Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-20 14:01 +0300
                    Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Melzzzzz <Melzzzzz@zzzzz.com> - 2018-11-20 11:07 +0000
                      Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-20 15:12 +0300
                    Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-20 08:15 -0500
                      Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-20 23:08 +0300
                        Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jameskuyper@alumni.caltech.edu - 2018-11-20 14:13 -0800
                          Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-21 16:38 +0300
                            Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-21 09:05 -0500
                              Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-21 20:28 +0300
                                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jameskuyper@alumni.caltech.edu - 2018-11-21 12:58 -0800
                                  Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-22 01:47 +0300
                                    Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jameskuyper@alumni.caltech.edu - 2018-11-21 15:50 -0800
                                      Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-24 19:37 +0300
                                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-21 21:22 +0000
                    Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-21 01:15 +0000
          Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-19 15:06 +0000
          Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] mark.bluemel@gmail.com - 2018-11-19 08:05 -0800
            Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] scott@slp53.sl.home (Scott Lurndal) - 2018-11-19 16:49 +0000
          Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jameskuyper@alumni.caltech.edu - 2018-11-19 10:35 -0800
            Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-20 00:45 +0300
              Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jameskuyper@alumni.caltech.edu - 2018-11-19 14:24 -0800
                Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-20 15:05 +0300
                  Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-20 08:31 -0500
                  Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Richard Damon <Richard@Damon-Family.org> - 2018-11-20 20:02 -0500
                    Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-21 22:47 +0300
                      Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] jameskuyper@alumni.caltech.edu - 2018-11-21 13:08 -0800
                        Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-22 00:31 +0300
                      Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-21 21:36 +0000
        Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-19 16:04 +0300
          Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-19 14:56 +0000
      Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-24 19:24 +0300
        Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-24 21:31 +0000
          Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-24 21:46 +0000
          Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-25 01:12 +0300
            Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-25 01:39 +0000
              Re: My dynamic arrays module [was:Re: Pointer conversion and alignment] Anton Shepelev <anton.txt@gmail.com> - 2018-11-25 14:19 +0300
    Re: Pointer conversion and alignment jadill33@gmail.com - 2018-11-19 08:44 -0800
      Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-20 00:02 +0300
        Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-11-19 13:51 -0800
          Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-20 01:08 +0300
            Re: Pointer conversion and alignment jameskuyper@alumni.caltech.edu - 2018-11-19 14:31 -0800
              Re: Pointer conversion and alignment Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-20 15:21 +0300
                Re: Pointer conversion and alignment James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-20 08:59 -0500
                  Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-11-20 11:06 -0800
                    Re: Pointer conversion and alignment jameskuyper@alumni.caltech.edu - 2018-11-20 12:43 -0800
                      Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-11-20 14:33 -0800
                        Re: Pointer conversion and alignment Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-21 14:33 +0300
                          Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-21 07:49 -0500
                            Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-11-21 12:42 -0800
                          Re: Pointer conversion and alignment James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-21 08:41 -0500
                  Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-25 15:06 +0300
                    Re: Pointer conversion and alignment James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-25 10:47 -0500
                      Re: Pointer conversion and alignment Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-26 12:42 +0300
                        Re: Pointer conversion and alignment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-26 03:07 -0800
                          Re: Pointer conversion and alignment Keith Thompson <kst-u@mib.org> - 2018-11-26 12:56 -0800
                            Re: Pointer conversion and alignment Richard Damon <Richard@Damon-Family.org> - 2018-11-26 18:17 -0500
                        Re: Pointer conversion and alignment jameskuyper@alumni.caltech.edu - 2018-11-26 09:06 -0800
                          Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-26 23:52 +0300
                            Re: Pointer conversion and alignment jameskuyper@alumni.caltech.edu - 2018-11-26 13:13 -0800
                              Re: Pointer conversion and alignment Anton Shepelev <anton.txt@gmail.com> - 2018-11-27 00:31 +0300
                                Re: Pointer conversion and alignment jameskuyper@alumni.caltech.edu - 2018-11-26 14:15 -0800
        Re: Pointer conversion and alignment jadill33@gmail.com - 2018-11-19 14:33 -0800

Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]

#138181

Richard Damon <Richard@Damon-Family.org> writes:
> On 11/21/18 6:33 AM, Anton Shepelev wrote:
>> Keith Thompson:
>> 
>>>    #include <stdio.h>
>>>
>>>    typedef int int2[2];
>>>
>>>    static void show(int2 *ptr) {
>>>        printf("%d %d0, (*ptr)[0], (*ptr)[1]);
>>>    }
>>>
>>>    int main(void) {
>>>        int arr[8] = { 1, 2, 3, 4, 5, 6, 7, 8 };
>>>        show((int2*)&arr[0]);
>>>        show((int2*)&arr[1]);
>>>    }
>> 
>> The effective type of the &arr[0] access is `pointer to
>> int', whereas you convert it into a pointer to an array of
>> two int values.  Is not this pointer conversion UB?  Even if
>> it successds, won't the accesses in show() violate aliasing?
>
> My understanding is that in C you rarely actually access an object of
> array type. All the accesses to the elements of arr are to object of
> type int, so we had no aliasing there.

True, but not relevant for this example, since I explicitly construct
a pointer to an array.

> We did create some temporary object of type pointer to int, and
then > converted them to pointer to array of int and placed that
value in a new > object (so no aliasing).

There is no temporary pointer object.  arr[0] is an object of type
int, and &arr[0] is a *value* (not an object) of type int*.

[...]

I've found a statement in the standard that very nearly says that
array types have the same alignment as their element types.  Section
6.2.8 "Alignment of objects" doesn't say so, but 6.5.3.4p3 says:

    The _Alignof operator yields the alignment requirement of its
    operand type. The operand is not evaluated and the result is
    an integer constant. When applied to an array type, the result
    is the alignment requirement of the element type.

So I think that answers my question: int[2] must have the same
alignment requirement as int.  More generally, some_type[N] must
have the same alignment requirement as some_type.

(There's a very strained reading that could allow int[2] to require
stricter alignment than int, but it doesn't make sense.)

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#138175

On 11/21/18 06:33, Anton Shepelev wrote:
> Keith Thompson:
> 
>>    #include <stdio.h>
>>
>>    typedef int int2[2];
>>
>>    static void show(int2 *ptr) {
>>        printf("%d %d0, (*ptr)[0], (*ptr)[1]);
>>    }
>>
>>    int main(void) {
>>        int arr[8] = { 1, 2, 3, 4, 5, 6, 7, 8 };
>>        show((int2*)&arr[0]);
>>        show((int2*)&arr[1]);
>>    }
> 
> The effective type of the &arr[0] access is `pointer to
> int', whereas you convert it into a pointer to an array of
> two int values.  Is not this pointer conversion UB?  Even if
> it successds, won't the accesses in show() violate aliasing?

Only objects in memory have effective types. &arr[0] is a pointer value
that is not stored in any C object. It points at an object with a
declared type of int, which is therefore also its effective type.

The two-element array of int that p points at is never accessed
directly. That array isn't accessed directly, only the elements of the
array are accessed, as is done by the expressions (*ptr)[0] and
(*ptr)[1]. Those expressions have the type "int", and the objects
referred to by those expressions have a declared type, and therefore, an
effective type, of "int", so there's no mis-match, and no aliasing problem.

If such expressions had been used to write into memory with no declared
type, they would have given two separate objects the effective type of
"int", rather than giving the two combined objects the type "int[2]"
(Note: I'm not sure that there's any practical difference between those
two cases). You could give memory with no declared type and effective
type that is an array type by copying from an array object into that
memory, using memcpy(), memmove(), or by copying it as an array of
character type (6.5p6).

C has two kinds of aggregate objects: arrays and structs. The situation
is different for structs. You can access an entire struct with a single
lvalue:

    const struct tm empty={0};
    struct tm *now = malloc(sizeof *now)
    if(now)
        *now = empty;

This code accesses "empty" for reading and "*now" for writing.

Note, in particular, that if the struct type contains an array, this is
a fourth way of giving memory with no declared type an effective type
that is an array.

Initializing an object, conversion of a function argument into a
function parameter, or returning a value from a function, all  behave
"as if by assignment". Therefore, all of those can also be used to
access an entire object of struct type with a single lvalue.

[toc] | [prev] | [next] | [standalone]

#138233

James Kuyper to Anton Shepelev:

> > What about the method Chris M. Thomasson's uses:
> >
> >    #define alignmentof(type) offsetof(struct { char c;type t;},t)
> >
> > Is the result of this macro connected with the alignment
> > of type t in any way?
>
> It's guaranteed to give a result that is an integer
> multiple of the alignment requirement, and on any
> reasonable implementation that multiple should be 1, but
> it's not guaranteed to be 1.
>
> But you can't use this fact to determine the minimum
> alignment requirement that's greater than 1, over all
> types.

I considered accepting the array element type in a macro and
determining a sufficient (and likely the minimal necessary)
alignment for that one type.

> Note: it's not quite clear to me why you're interested in
> the minimum alignment requirement. Perhaps I been
> misinterpreting something you said earlier?

Either I didn't say that or you misunderstood: I am
interested in the minimum alignment sufficient for any type.
With all alignments being powers of two, it is equivalent to
the maximum alignment requirement over all types.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#138234

On 11/25/18 07:06, Anton Shepelev wrote:
> James Kuyper to Anton Shepelev:
...
>> Note: it's not quite clear to me why you're interested in
>> the minimum alignment requirement. Perhaps I been
>> misinterpreting something you said earlier?
> 
> Either I didn't say that or you misunderstood: I am
> interested in the minimum alignment sufficient for any type.
> With all alignments being powers of two, it is equivalent to
> the maximum alignment requirement over all types.

Even when alignments were not required to be a power of two, it's still
equivalent to the maximum alignment requirement over all types. Which is
why I was confused by your labeling it as a minimum. "minimum
sufficient" is built into the concept of "alignment requirement". An
alignment bigger than the minimum is NOT a requirement.

[toc] | [prev] | [next] | [standalone]

#138241

James Kuyper to Anton Shepelev:

>>James Kuyper:
>>
>>>Note: it's not quite clear to me why you're interested in
>>>the minimum alignment requirement. Perhaps I been
>>>misinterpreting something you said earlier?
>>
>>Either I didn't say that or you misunderstood: I am
>>interested in the minimum alignment sufficient for any
>>type.  With all alignments being powers of two, it is
>>equivalent to the maximum alignment requirement over all
>>types.
>
>Even when alignments were not required to be a power of
>two, it's still equivalent to the maximum alignment
>requirement over all types.

Suppose there are two types with alignments 3 and 5.  The
maximum alignment over these two is 5, yet the miminum
sufficient alignment is 15.

>Which is why I was confused by your labeling it as a
>minimum. "minimum sufficient" is built into the concept of
>"alignment requirement". An alignment bigger than the
>minimum is NOT a requirement.

An alignment requirement is a property of a single type,
whereas I was interested in a similar property for a set of
types, namely -- the set of all types.  I think it is a
constant used in malloc() in order to generate only such
addresses as are multiples of this constant.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#138243

On Monday, November 26, 2018 at 9:42:15 AM UTC, Anton Shepelev wrote:
>
> Suppose there are two types with alignments 3 and 5.  The
> maximum alignment over these two is 5, yet the miminum
> sufficient alignment is 15.
>
Whilst C allows this, in fact processors are not built that way. 
>
> An alignment requirement is a property of a single type,
> whereas I was interested in a similar property for a set of
> types, namely -- the set of all types.  I think it is a
> constant used in malloc() in order to generate only such
> addresses as are multiples of this constant.
> 
Yes, in practice malloc() is written in a platform-dependent manner,
and the alignment suitable for any use is just one of the many
non-portable bits of the code. You can generate a union of all basic
types and declare your allocation pool to be an array of that, together
with a block-control structure added to the union. Then you have a
portable malloc, but not a very good one, as it has no way of knowing
how much memory is actually available to the process and allocates from
a fixed arena.

[toc] | [prev] | [next] | [standalone]

#138274

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, November 26, 2018 at 9:42:15 AM UTC, Anton Shepelev wrote:
>> Suppose there are two types with alignments 3 and 5.  The
>> maximum alignment over these two is 5, yet the miminum
>> sufficient alignment is 15.
>>
> Whilst C allows this, in fact processors are not built that way. 

In fact C does not allow this.

N1570 6.2.8p4: "Every valid alignment value shall be a nonnegative
integral power of two."

[...]

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#138283

On 11/26/18 3:56 PM, Keith Thompson wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On Monday, November 26, 2018 at 9:42:15 AM UTC, Anton Shepelev wrote:
>>> Suppose there are two types with alignments 3 and 5.  The
>>> maximum alignment over these two is 5, yet the miminum
>>> sufficient alignment is 15.
>>>
>> Whilst C allows this, in fact processors are not built that way. 
> 
> In fact C does not allow this.
> 
> N1570 6.2.8p4: "Every valid alignment value shall be a nonnegative
> integral power of two."
> 
> [...]
> 

But it used to.

[toc] | [prev] | [next] | [standalone]

#138265

On Monday, November 26, 2018 at 4:42:15 AM UTC-5, Anton Shepelev wrote:
> James Kuyper to Anton Shepelev:
...
[Context: in C2011 there is a new requirement that all alignment
requirements must be a powers of 2. The committee presumably added this
requirement in the belief that there are no existing implementations
violating this requirement. The following comments refer to a
hypothetical implementation conforming to an earlier version of the
standard, where that requirement was not present:]

> Suppose there are two types with alignments 3 and 5.  The
> maximum alignment over these two is 5, yet the miminum
> sufficient alignment is 15.
> 
> >Which is why I was confused by your labeling it as a
> >minimum. "minimum sufficient" is built into the concept of
> >"alignment requirement". An alignment bigger than the
> >minimum is NOT a requirement.
> 
> An alignment requirement is a property of a single type,
> whereas I was interested in a similar property for a set of
> types, namely -- the set of all types.  I think it is a
> constant used in malloc() in order to generate only such
> addresses as are multiples of this constant.

The minimum sufficient alignment is always also, necessarily, the
alignment of multiple specific types. For instance, on the
implementation that you postulate, any struct or union that includes at
least one member with an alignment requirement of 3, and one member
with an alignment requirement of 5, would necessarily have an alignment
requirement of it's own that is a positive integer multiple of 15 (it
would presumably be exactly 15, but that was not required). The minimum
sufficient alignment is therefore inherently the same as the maximum
alignment requirement over all types.

[toc] | [prev] | [next] | [standalone]

#138273

James Kuyper to Anton Shepelev:

> [Context: in C2011 there is a new requirement that all
> alignment requirements must be a powers of 2. The
> committee presumably added this requirement in the belief
> that there are no existing implementations violating this
> requirement. The following comments refer to a
> hypothetical implementation conforming to an earlier
> version of the standard, where that requirement was not
> present:]
>
> > Suppose there are two types with alignments 3 and 5.
> > The maximum alignment over these two is 5, yet the
> > miminum sufficient alignment is 15.
> >
> > > Which is why I was confused by your labeling it as a
> > > minimum. "minimum sufficient" is built into the
> > > concept of "alignment requirement". An alignment
> > > bigger than the minimum is NOT a requirement.
> >
> > An alignment requirement is a property of a single type,
> > whereas I was interested in a similar property for a set
> > of types, namely -- the set of all types.  I think it is
> > a constant used in malloc() in order to generate only
> > such addresses as are multiples of this constant.
>
> The minimum sufficient alignment is always also,
> necessarily, the alignment of multiple specific types. For
> instance, on the implementation that you postulate, any
> struct or union that includes at least one member with an
> alignment requirement of 3, and one member with an
> alignment requirement of 5, would necessarily have an
> alignment requirement of it's own that is a positive
> integer multiple of 15 (it would presumably be exactly 15,
> but that was not required). The minimum sufficient
> alignment is therefore inherently the same as the maximum
> alignment requirement over all types.

I misinterpreted your term "maximum over" literally as the
maximum value in a set:

                      max({3,5}) = 5,

whereas you meant the alignment of a struct of union that
includes several types, in which case

             maxalign({3,5}) = LCM({3,5}) = 15.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#138276

On Monday, November 26, 2018 at 3:52:18 PM UTC-5, Anton Shepelev wrote:
> James Kuyper to Anton Shepelev:
> 
> > [Context: in C2011 there is a new requirement that all
> > alignment requirements must be a powers of 2. The
> > committee presumably added this requirement in the belief
> > that there are no existing implementations violating this
> > requirement. The following comments refer to a
> > hypothetical implementation conforming to an earlier
> > version of the standard, where that requirement was not
> > present:]
> >
> > > Suppose there are two types with alignments 3 and 5.
> > > The maximum alignment over these two is 5, yet the
> > > miminum sufficient alignment is 15.
> > >
> > > > Which is why I was confused by your labeling it as a
> > > > minimum. "minimum sufficient" is built into the
> > > > concept of "alignment requirement". An alignment
> > > > bigger than the minimum is NOT a requirement.
> > >
> > > An alignment requirement is a property of a single type,
> > > whereas I was interested in a similar property for a set
> > > of types, namely -- the set of all types.  I think it is
> > > a constant used in malloc() in order to generate only
> > > such addresses as are multiples of this constant.
> >
> > The minimum sufficient alignment is always also,
> > necessarily, the alignment of multiple specific types. For
> > instance, on the implementation that you postulate, any
> > struct or union that includes at least one member with an
> > alignment requirement of 3, and one member with an
> > alignment requirement of 5, would necessarily have an
> > alignment requirement of it's own that is a positive
> > integer multiple of 15 (it would presumably be exactly 15,
> > but that was not required). The minimum sufficient
> > alignment is therefore inherently the same as the maximum
> > alignment requirement over all types.
> 
> I misinterpreted your term "maximum over" literally as the
> maximum value in a set:
> 
>                       max({3,5}) = 5,
> 
> whereas you meant the alignment of a struct of union that
> includes several types, in which case
> 
>              maxalign({3,5}) = LCM({3,5}) = 15.

No, that distinction has nothing to do with our communications problem. When I said "the maximum alignment requirement over all types", I meant "maximum ... over" in precisely the sense you give above: max({3,5,15}) = 15. The key question that needs to be addressed is why you do not include 15 in the set, and I do. It is described as "over all types". If, for example, a C99 implementation had an "int" type with an alignment requirement of 3, and a "long int" type with an alignment requirement of 5, then struct int_long{ int i; long l;} is a type, and the alignment requirement for that type is at least 15; let's assume for simplicity that it's exactly 15. The set of all types includes "struct int_long". Therefore the set of alignment requirements for all types includes 15.
Why is 15 missing from your list of alignment requirements for all types?

[toc] | [prev] | [next] | [standalone]

#138279

James Kuyper to Anton Shepelev:

> > James Kuyper to Anton Shepelev:
> >
> > > [Context: in C2011 there is a new requirement that all
> > > alignment requirements must be a powers of 2. The
> > > committee presumably added this requirement in the
> > > belief that there are no existing implementations
> > > violating this requirement. The following comments
> > > refer to a hypothetical implementation conforming to
> > > an earlier version of the standard, where that
> > > requirement was not present:]
> > >
> > > > Suppose there are two types with alignments 3 and 5.
> > > > The maximum alignment over these two is 5, yet the
> > > > miminum sufficient alignment is 15.
> > > >
> > > > > Which is why I was confused by your labeling it as
> > > > > a minimum. "minimum sufficient" is built into the
> > > > > concept of "alignment requirement". An alignment
> > > > > bigger than the minimum is NOT a requirement.
> > > >
> > > > An alignment requirement is a property of a single
> > > > type, whereas I was interested in a similar property
> > > > for a set of types, namely -- the set of all types.
> > > > I think it is a constant used in malloc() in order
> > > > to generate only such addresses as are multiples of
> > > > this constant.
> > >
> > > The minimum sufficient alignment is always also,
> > > necessarily, the alignment of multiple specific types.
> > > For instance, on the implementation that you
> > > postulate, any struct or union that includes at least
> > > one member with an alignment requirement of 3, and one
> > > member with an alignment requirement of 5, would
> > > necessarily have an alignment requirement of it's own
> > > that is a positive integer multiple of 15 (it would
> > > presumably be exactly 15, but that was not required).
> > > The minimum sufficient alignment is therefore
> > > inherently the same as the maximum alignment
> > > requirement over all types.
> >
> > I misinterpreted your term "maximum over" literally as
> > the maximum value in a set:
> >
> >                     max({3,5}) = 5,
> >
> > whereas you meant the alignment of a struct of union
> > that includes several types, in which case
> >
> >            maxalign({3,5}) = LCM({3,5}) = 15;
> >
> No, that distinction has nothing to do with our
> communications problem. When I said "the maximum alignment
> requirement over all types", I meant "maximum ... over" in
> precisely the sense you give above: max({3,5,15}) = 15.
> The key question that needs to be addressed is why you do
> not include 15 in the set, and I do. It is described as
> "over all types". If, for example, a C99 implementation
> had an "int" type with an alignment requirement of 3, and
> a "long int" type with an alignment requirement of 5, then
> struct int_long{ int i; long l;} is a type, and the
> alignment requirement for that type is at least 15; let's
> assume for simplicity that it's exactly 15. The set of all
> types includes "struct int_long". Therefore the set of
> alignment requirements for all types includes 15.  Why is
> 15 missing from your list of alignment requirements for
> all types?

I wrongly assumed it referred to the scalar types only.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#138281

On Monday, November 26, 2018 at 4:31:53 PM UTC-5, Anton Shepelev wrote:
> James Kuyper to Anton Shepelev:
> 
> > > James Kuyper to Anton Shepelev:
> > >
> > > > [Context: in C2011 there is a new requirement that all
> > > > alignment requirements must be a powers of 2. The
> > > > committee presumably added this requirement in the
> > > > belief that there are no existing implementations
> > > > violating this requirement. The following comments
> > > > refer to a hypothetical implementation conforming to
> > > > an earlier version of the standard, where that
> > > > requirement was not present:]
> > > >
> > > > > Suppose there are two types with alignments 3 and 5.
> > > > > The maximum alignment over these two is 5, yet the
> > > > > miminum sufficient alignment is 15.
> > > > >
> > > > > > Which is why I was confused by your labeling it as
> > > > > > a minimum. "minimum sufficient" is built into the
> > > > > > concept of "alignment requirement". An alignment
> > > > > > bigger than the minimum is NOT a requirement.
> > > > >
> > > > > An alignment requirement is a property of a single
> > > > > type, whereas I was interested in a similar property
> > > > > for a set of types, namely -- the set of all types.
> > > > > I think it is a constant used in malloc() in order
> > > > > to generate only such addresses as are multiples of
> > > > > this constant.
> > > >
> > > > The minimum sufficient alignment is always also,
> > > > necessarily, the alignment of multiple specific types.
> > > > For instance, on the implementation that you
> > > > postulate, any struct or union that includes at least
> > > > one member with an alignment requirement of 3, and one
> > > > member with an alignment requirement of 5, would
> > > > necessarily have an alignment requirement of it's own
> > > > that is a positive integer multiple of 15 (it would
> > > > presumably be exactly 15, but that was not required).
> > > > The minimum sufficient alignment is therefore
> > > > inherently the same as the maximum alignment
> > > > requirement over all types.
> > >
> > > I misinterpreted your term "maximum over" literally as
> > > the maximum value in a set:
> > >
> > >                     max({3,5}) = 5,
> > >
> > > whereas you meant the alignment of a struct of union
> > > that includes several types, in which case
> > >
> > >            maxalign({3,5}) = LCM({3,5}) = 15;
> > >
> > No, that distinction has nothing to do with our
> > communications problem. When I said "the maximum alignment
> > requirement over all types", I meant "maximum ... over" in
> > precisely the sense you give above: max({3,5,15}) = 15.
> > The key question that needs to be addressed is why you do
> > not include 15 in the set, and I do. It is described as
> > "over all types". If, for example, a C99 implementation
> > had an "int" type with an alignment requirement of 3, and
> > a "long int" type with an alignment requirement of 5, then
> > struct int_long{ int i; long l;} is a type, and the
> > alignment requirement for that type is at least 15; let's
> > assume for simplicity that it's exactly 15. The set of all
> > types includes "struct int_long". Therefore the set of
> > alignment requirements for all types includes 15.  Why is
> > 15 missing from your list of alignment requirements for
> > all types?
> 
> I wrongly assumed it referred to the scalar types only.

That's problematic: if you only consider scalar types, you won't
necessarily include all alignment requirements. It's entirely
permissible for a struct or union to have an alignment requirement
that's stricter than required for the types of it's members, and I've
heard of real world implementations that do so. They give all struct
types the same alignment requirement as the strictest scalar type,
regardless of the types of the struct's members.

While I have NOT heard of an implementation where a struct had an
alignment requirement stricter than the most strictly aligned scalar
type, an implementation that imposed such a requirement wouldn't violate
any requirement of the standard. The scalar types might have alignment
requirements motivated by the sizes of a system's register, with a
maximum of say, 8 bytes, while the alignment requirement for structs
(possibly only for structs larger than a specific minimum size) might be
motivated by the size of memory pages (say, 16 bytes).

Thus, your "minimum sufficient alignment" cannot necessarily be
determined by looking only at the alignment requirements of scalar
types.

[toc] | [prev] | [next] | [standalone]

#138141

On Monday, November 19, 2018 at 4:02:37 PM UTC-5, Anton Shepelev wrote:
> Thank you for the reply, jadill33:
> 
> > If you're looking at making "fat" pointers to your array,
> > you'll need to depend on a max_align_t or ALIGN_MAX of
> > some kind so that your data and your structure are aligned
> > to that value.
> 
> Not even in C99.

There's workarounds for C90.

> > Take for example a simple "fat" pointer where you want to
> > store the size of the allocation.  You are guaranteed by
> > the standard that malloc provides an address that is
> > maximally aligned for any type by the implementation.  If
> > you do the naive approach where you attach a sizeof type
> > to the data, your array won't be aligned for types whose
> > alignment is > size_t.
> 
> Sounds logical, but I fail to see how it is formally true of
> the standard, which seems to allow types of the same size to
> have different alignments...

Since 'malloc' is not getting passed an alignment constraint to allocate
memory for an 'int' or a 'double' type, malloc has to assume the largest
alignment constraint available for all types.  Commonly, the type 'double'
has the same alignment as the maximum alignment type, but it's not guaranteed.

If 'int' has an alignment of 4 bytes, then it can be assigned to addresses
in multiples of 4.

0x00000004
0x00000008
0x0000000C
0x00000010
0x00000014
0x00000018
0x0000001C
0x00000020

If 'double' has an alignment of 8 bytes, then it can be assigned to addresses
in multiples of 8.

0x00000008
0x00000010
0x00000018
0x00000020

If an allocation of 'double' to a pointer is assigned to an address 0x00000004
or 0x0000000C, then that is an alignment mismatch and can cause seg faults
on computers like alpha or sun.  Other architectures may be forgiving and
let you still access the memory at a performance cost.  Multiple words may
need to be fetched and then stitched together using shifts, 'and' and 'or'
operations to get your value.

All 'malloc' is getting is a size in bytes.  So if 'double' has an alignment
of '8', then 'int' must be allocated with an alignment of '8'.

> > void* track_malloc( size_t size )
> > {
> >   void* p = NULL;
> >   void* mem;
> >
> >   mem = malloc( sizeof (size_t) + size );
> >
> >   if ( mem )
> >   {
> >     *((size_t*)mem) = size;
> >     p = (unsigned char*)mem + sizeof (size_t);
> >   }
> >
> >   return p;
> > }
> >
> >     ---------- --------------------
> >    |  size_t  |       object       |
> >     ---------- --------------------
> >    /          /
> > mem          p
> >
> > When it comes time to free the object, one needs to factor in the
> > attached 'size_t' object and free the entire memory block.
> >
> > void track_free( void* p )
> > {
> >   void* mem;
> >   if ( p )
> >   {
> >     mem = (unsigned char*)p - sizeof (size_t);
> >     free( mem );
> >   }
> > }
> 
> That is basically what I do too.
> 
> > However, if you know the max_align_t size for your system, you can allocate
> > integer multiples of that value and place the data at that offset.
> >
> > #define c_maxalign_sizeof(type) ( c_align_size( sizeof (type), ALIGN_MAX ) )
> >
> >             c_maxalign_sizeof example
> >  -----------------------------------------------
> > |       type       | sizeof | c_maxalign_sizeof |
> >  -----------------------------------------------
> >   char               1        8
> >   short int          2        8
> >   int                4        8
> >   long int           4        8
> >   long long int      8        8
> >   float              4        8
> >   double             8        8
> >   long double        12       16
> >   size_t             4        8
> >   ptrdiff_t          4        8
> >   void*              4        8
> >   struct c_timeval   16       16
> >   struct c_list      12       16
> >   struct c_array     28       32
> >
> > ALIGN_MAX = 8
> >
> > This is output from my sample program.  It depends on c_align_size and
> > ALIGN_MAX.
> 
> Does it meant that int's occupy four bytes in memory yet
> must be aligned to eight bytes?  You must have a 64-bit
> system and compiler, right?

If 'int' is 4-bytes, then that is the maximum alignment required to access
an 'int' via a pointer int*.  It could technically be smaller if the
architecture focused on 16-bit words instead of 32-bit words.  However,
'malloc' must assume that the alignment is that of the maximum alignment of
any type, so that 'int' would be restricted to addresses in a multiple of '8'.

Here's a sample output of the 'alignof' for the types on my system.  My
computer supports 64-bits, but it doesn't restrict the alignment of 'int'
to 8.

            alignof example
 -------------------------------------
|       type       | sizeof | alignof |
 -------------------------------------
  char               1        1
  short int          2        2
  int                4        4
  long int           4        4
  long long int      8        8
  float              4        4
  double             8        8
  long double        12       4
  size_t             4        4
  ptrdiff_t          4        4
  void*              4        4
  enum align_e       4        4
  struct align_s     16       8
  align_func         4        4

ALIGN_MAX = 8

> > Chris Thomasson has some wizardry to get that value based
> > on using an 'alignof' macro based on 'offsetof' and a
> > union with a wide enough selection of types to get all the
> > possible combinations of types with different alignments.
> 
> Is not another option to expose the array constructor as a
> macro taking the element type as an argument and calcuating
> the alignment with
> 
>   #define alignmentof(type) offsetof(struct { char c;type t;},t)

/* The symbol 'stdalign_alignof_defined' is temporarily used to
   record whether or not the 'alignof' macro is available. */
#undef stdalign_alignof_defined

/*
 * If C11 standard support is available, then 'alignof' is directly
 * available.
 */
#if defined(__STDC__) && defined(__STDC_VERSION__)
#  if (__STDC__ && __STDC_VERSION__ >= 201112L)
#    include <stdalign.h>
#    if defined(__alignof_is_defined)
#      define stdalign_alignof_defined
#    endif
#  endif
#endif

/*!
 * \brief Determine the alignment of the type in bytes.
 * \param type A type.
 *
 * The number of bytes returned is not guaranteed to be the smallest
 * alignment allowed by the platform if \c alignof is not natively
 * available from the compiler.  Without \c alignof, the \c offsetof
 * operator can determine a compatible alignment for the given type.
 */
#if !defined(stdalign_alignof_defined)
#  define alignof(type) (offsetof (struct { char c; type t; }, t))
#endif

#undef stdalign_alignof_defined

#if !defined(ALIGN_MAX)

enum gc_align_e
{
  GC_ALIGN_ENUM_1,
  GC_ALIGN_ENUM_2
};
struct gc_align_s
{
  double d;
};

/* The function pointer type is a typedef to avoid syntax problems
   with the definition of the alignof macro. */
typedef double (*gc_align_func)( double );

/*
 * Ideally, the 'gc_align_max' union should contain every possible C
 * type.  That is simply not possible, so the best one can do is use
 * a wide variety of common C types.
 */
union gc_align_max
{
  char c;
  short int si;
  int i;
  long int li;
#if defined(LLONG_MAX)
  long long int lli;
#endif
  float f;
  double d;
  long double ld;
  size_t sz;
  ptrdiff_t diff;
  void* p;
  enum gc_align_e ae;
  struct gc_align_s as;
  gc_align_func af;
};

/*!
 * \brief An estimate of the maximum alignment for any type.
 *
 * The \c ALIGN_MAX constant is not guaranteed to represent the
 * maximum alignment of any type because its "union of all types"
 * may not include a type with a larger alignment restriction.
 *
 * If one discovers a type with an alignment restriction larger than
 * the set of types used to determine the \c ALIGN_MAX constant, just
 * add the type to the <tt>union gc_align_max</tt> declaration.
 */
#define ALIGN_MAX (alignof (union gc_align_max))
#endif

This is largely inspired by Chris Thomasson's stuff he posted quite a while
back.  However, I don't know how well it will fair on exotic architectures.
 
> > c_align_size is a simple function that takes a size and
> > rounds it to a multiple of a specified alignment.
> > [...]  With this in place, you can replace your special
> > malloc functions with
> >
> > p   = (unsigned char*)mem + c_maxalign_sizeof (size_t);
> > mem = (unsigned char*)p   - c_maxalign_sizeof (size_t);
> 
> Why do you use unsigned char instead of char?  Why do you
> pass to c_maxalign_sizeof size_t instead of the type of the
> array element?

You have three elements you want to store with the data.  If you define the
data in a structure, you could have something like:

struct array_hdr
{
  int length;
  int capacity;
  size_t size;
};

If the struct is aligned to the max alignment of the implementation, then
you're guaranteed that you can access 'length', 'capacity', and 'size' without
any alignment snafus.  It's a bit more crumbly if you store individual
elements like your code is showing.

Let's say for argument's sake that 'int' and 'size_t' are both 4.  If you
package your header and data together without regard for alignment, you
could have this:

| length | capacity | size | double array |
0        4          8      C*

Now, you've messed up your alignment of your data because your 12 byte
structure caused your 'double' array of data to be misaligned.  You can
fix that by using maxalign_sizeof to round up the size to a multiple of
the max alignment so that you'd have

| length | capacity | size | pad | double array
0        4          8      C     10

Now your data is properly aligned and won't crash on suns.

It's possible to have an 'int' of 4 but a 'size_t' of 8.  Using the
maxalign_sizeof, you don't have to go in and tweak each time a new
architecture comes up.

I also recommend using a structure over using individual data elements.
You can cast the origin pointer to the structure and set the elements
individually, then return a pointer to an offset of maxalign_sizeof
array_hdr after you fill in the data.

Best regards,
John D.

[toc] | [prev] | [standalone]

Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]

Back to top | Article view | comp.lang.c

csiph-web