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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

#138087

On 18/11/18 10:57, Malcolm McLean wrote:
> On Saturday, November 17, 2018 at 9:49:44 PM UTC, Keith Thompson wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>> On 18/11/18 03:52, Malcolm McLean wrote:
>>>> On Saturday, November 17, 2018 at 11:38:29 AM UTC, Anton Shepelev wrote:
>>>>> By way of exercise, I am writing a small dynamic array
>>>>> library that makes dynamic arrays appear and behave as if
>>>>> they were pointers to allocated objects of the corresponding
>>>>> type, so that they can be substituded for such pointers
>>>>> without rewriting the code.
>>>>>
>>>> For practical purposes, you can write a malloc() family function
>>>> by aligning to double, which will be the most strictly aligned type.
>>>
>>> long double is a safer bet.
>>
>> Use max_align_t if it's available (I think it was introduced in C11).
>>
>> If not, using a union containing members of types long, long long,
>> intmax_t, double, long double, void*, and void(*)(void) is very
>> likely to be good enough.  (I'm thinking about the possibility
>> of long double being implemented in software, and not requiring
>> an alignment as strict as double.  I have no idea whether such
>> implementations exist, but an extra line in the union definition
>> is cheap.)
>>
> long double is often 10 8-bit bytes. double is almost always 8.
> So actually you would expect double to have the stricter alignment
> requirements.

No, you wouldn't.  A long double is at least as "long" as a double.  On 
some platforms (such as SPARC) uses a full 128 bits.  On x86 Linux, 
sizeof(long double) == 16.

> However there's no agreement on what long double should be.

At least as "long" as a double.

-- 
Ian.

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

#138089

Ian Collins to Malcolm McLean:

> > However there's no agreement on what long double should
> > be.
>
> At least as "long" as a double.

I can understand this.  The programmer asks the compiler to
give him a type longer than double if it is available, and
fall back to double if it is not.

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

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

#138098

Anton Shepelev <anton.txt@gmail.com> writes:
> Ian Collins to Malcolm McLean:
>> > However there's no agreement on what long double should
>> > be.
>>
>> At least as "long" as a double.
>
> I can understand this.  The programmer asks the compiler to
> give him a type longer than double if it is available, and
> fall back to double if it is not.

Sort of.  long double can have the same representation as double, but
it's still a distinct type.  Rather than "fall back to double", I'd say
it can fall back to the same size, representation, range, and precision
as double.

-- 
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]

#138105

Am 17.11.18 um 22:49 schrieb Keith Thompson:
> 
> Use max_align_t if it's available (I think it was introduced in C11).
> 
> If not, using a union containing members of types long, long long,
> intmax_t, double, long double, void*, and void(*)(void) is very
> likely to be good enough.

Including pointer types is a good suggestion: Padauk makes 8-bit
microcontrollers that do not have any alignment requirements on "normal"
data, so a double implemented in software could be at any address. But
pointers need to be aligned to 16-bit boundaries.

On the other hand, AFAIK their "Mini-C" does not support double. While
there are plans for an SDC backend, SDCC has max_align_t anyway.

Philipp

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

#138080

On 11/17/18 6:38 AM, Anton Shepelev wrote:
> By way of exercise, I am writing a small dynamic array
> library that makes dynamic arrays appear and behave as if
> they were pointers to allocated objects of the corresponding
> type, so that they can be substituded for such pointers
> without rewriting the code.  The following sample (without
> error handling for simplicity):
> 
>    #include <stdio.h>
>    #include <stdlib.h>
>    #include <string.h>
>    #include "dynarray.h"
>    /* ... */
>    int *a, v, i, l;
>    void* vP;
> 
>    da_new ( &a, sizeof( int ) );
> 
>    da_setlen( &a, 2 );
>    a[0] = 0;
>    a[1] = 1;
> 
>    da_setlen( &a, 4 );
>    a[2] = 2;
>    a[3] = 3;
> 
>    v = 4;
>    da_add( &a, &v );
> 
>    v = 5;
>    da_addemp( &a, &vP );
>    memcpy( vP, &v, sizeof( int ) );
> 
>    l = da_len( &a );
>    for( i = 0; i < l; i++ )
>    {  printf("%i ", a[i]);  }
> 
>    da_free( &a );
> 
> prints: "0 1 2 3 4 5 ", but in order to make sure that my
> implementation works not by coincidence but by design, I
> need a better understanding of alignment, which the Standard
> defines as:
> 
>    requirement that objects of a particular type be located
>    on storage boundaries with addresses that are particular
>    multiples of a byte address.
> 
> Futher it mentions "alignment requirements" but never gives
> any.  What, for example, may be the alignment requirements
> for the types `char' and `pointer to char'?

The "alignment requirements" are implementation defined, as they vary
based on the host processor (and sometimes some additional factors). For
some machines (particularly 8 bit processors) any object can just be
byte aligned, on others some larger objects need to be aligned something
more strict, often the size of the object or the memory bus. Some
machines this requirement is 'weak' in that the machine can access
mis-aligned objects, just it is significantly more expensive to do so.
Because of C's array rules, no object can require an alignment bigger
than the size of that object.

The type 'char', therefore must have the weakest alignment, and any byte
address will work, since the size of a char is a single byte. That says
that the VALUE of a pointer to char, can be any byte address. The
LOCATION of a pointer to char may need to be more strictly aligned.
> 
> On pointers --
> 
>    A pointer to void shall have the same representation and
>    alignment requirements as a pointer to a character type.
>    Similarly, pointers to qualified or unqualified versions
>    of compatible types shall have the same representation
>    and alignment requirements.
>    [...]
>    A pointer to an object or incomplete type may be
>    converted to a pointer to a different object or
>    incomplete type. If the resulting pointer is not
>    correctly aligned for the pointed-to type, the behavior
>    is undefined.
> 
> How may one know whether a char pointer is "correctly
> aligned for" int?  Can one, for example, take an int* and
> read it byte-by-byte through a pointer to char* converted
> from the int pointer?
> 
> How does malloc() work --
> 
>    The pointer returned if the allocation succeeds is
>    suitably aligned so that it may be assigned to a pointer
>    to any type of object and then used to access such an
>    object or an array of such objects
> 
> Is not such an assignment, in terms of the standard, a
> conversion of one pointer type to another?  And if so, does
> not it imply that void pointers (and therefore char
> pointers) are somehow "correctly aligned for" any pointed-to
> type, whatever that means?  Notice that the sentence above
> says nothing the about the alignment of the actual allocated
> object created upon successful invocation of malloc().  Why
> does it not matter?  I suspected that calloc() performed
> some alignment based on its `size' parameter, but I was
> wrong.

In general, malloc and family will return pointers that are aligned to
the most strict alignment required by the system. While it is possible
that it could give less strict alignment for small allocations, this
doesn't happen in many systems.

> 
> If the alignment of a pointer is, by definition above, its
> location on storage boundaries, then what does it have to do
> with access to the pointed-to alocated objects?  If not,
> then where is pointer alignment defined, perhaps with
> respect to a pointed-to type?
> 

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

#138088

Richard Damon:

> In general, malloc and family will return pointers that
> are aligned to the most strict alignment required by the
> system.

When that is the case, I can allocate many times fewer
single-char objects than there are free bytes in memory,
because each separate allocation of a char effectively uses
up the size of the largest allocation multiple.

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

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

#138091

On 11/17/2018 2:08 PM, Anton Shepelev wrote:
> Richard Damon:
> 
>> In general, malloc and family will return pointers that
>> are aligned to the most strict alignment required by the
>> system.
> 
> When that is the case, I can allocate many times fewer
> single-char objects than there are free bytes in memory,
> because each separate allocation of a char effectively uses
> up the size of the largest allocation multiple.
> 

Check this hack out:

https://groups.google.com/forum/#!original/comp.lang.c/7oaJFWKVCTw/sSWYU9BUS_QJ

https://pastebin.com/raw/f37a23918

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

#138096

On 11/17/2018 2:31 PM, Chris M. Thomasson wrote:
> On 11/17/2018 2:08 PM, Anton Shepelev wrote:
>> Richard Damon:
>>
>>> In general, malloc and family will return pointers that
>>> are aligned to the most strict alignment required by the
>>> system.
>>
>> When that is the case, I can allocate many times fewer
>> single-char objects than there are free bytes in memory,
>> because each separate allocation of a char effectively uses
>> up the size of the largest allocation multiple.
>>
> 
> Check this hack out:
> 
> https://groups.google.com/forum/#!original/comp.lang.c/7oaJFWKVCTw/sSWYU9BUS_QJ 
> 
> 
> https://pastebin.com/raw/f37a23918

You might be interested in the following macro:
___________
#define RALLOC_ALIGN_OF(mp_type) \
   offsetof( \
     struct { \
       char pad_RALLOC_ALIGN_OF; \
       mp_type type_RALLOC_ALIGN_OF; \
     }, \
     type_RALLOC_ALIGN_OF \
   )
___________

;^)

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

#138102

Chris M. Thomasson:

> > https://pastebin.com/raw/f37a23918
>
> You might be interested in the following macro:
> ___________ #define RALLOC_ALIGN_OF(mp_type) \
>    offsetof( \
>      struct { \
>        char pad_RALLOC_ALIGN_OF; \
>        mp_type type_RALLOC_ALIGN_OF; \
>      }, \
>      type_RALLOC_ALIGN_OF \
>    ) ___________

This offset gives you alignment, which you then use in
RALLOC_ALIGN_UP in a way I don't understand:

   #define RALLOC_ALIGN_UP(mp_ptr, mp_align) \
     ((void*)( \
       (((ralloc_uintptr_type)(mp_ptr)) + ((mp_align) - 1)) \
       & ~(((mp_align) - 1)) \
     ))

Suppose mp_ptr is 5 and mp_align is 3:

   (5 + 2) & (~2) = 111b & 101b = 101b = 5

and 5 is not divisible by 3.  Is it supposed to work for
powers of two alone?

Why do you treat zero size as unity in rallocex():

     if (! size) {
       size = 1;
     }

How can its `align' argument be zero:

     if (! align) {
       align = RALLOC_ALIGN_MAX;
     }

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

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

#138103

On 11/18/18 07:01, Anton Shepelev wrote:
> Chris M. Thomasson:
> 
>>> https://pastebin.com/raw/f37a23918
>>
>> You might be interested in the following macro:
>> ___________ #define RALLOC_ALIGN_OF(mp_type) \
>>    offsetof( \
>>      struct { \
>>        char pad_RALLOC_ALIGN_OF; \
>>        mp_type type_RALLOC_ALIGN_OF; \
>>      }, \
>>      type_RALLOC_ALIGN_OF \
>>    ) ___________
> 
> This offset gives you alignment, which you then use in

Strictly speaking, it could be an integer multiple of the alignment -
implementations are allowed arbitrary padding between consecutive
non-bit-field members of a struct. But it's extermely unlikely.

> RALLOC_ALIGN_UP in a way I don't understand:
> 
>    #define RALLOC_ALIGN_UP(mp_ptr, mp_align) \
>      ((void*)( \
>        (((ralloc_uintptr_type)(mp_ptr)) + ((mp_align) - 1)) \
>        & ~(((mp_align) - 1)) \
>      ))
> 
> Suppose mp_ptr is 5 and mp_align is 3:
> 
>    (5 + 2) & (~2) = 111b & 101b = 101b = 5
> 
> and 5 is not divisible by 3.  Is it supposed to work for
> powers of two alone?

As of C2011, alignment requirements are now required to be powers of 2.
The committee made that decision because they couldn't find any examples
of platforms for which that wasn't the case. Therefore, my lovely
examples using types with mutually prime alignment requirements are no
longer valid. More importantly, the issue probably never actually came
up even when such an implementation would have been conforming.

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

#138146

On 11/18/2018 4:25 AM, James Kuyper wrote:
> On 11/18/18 07:01, Anton Shepelev wrote:
>> Chris M. Thomasson:
>>
>>>> https://pastebin.com/raw/f37a23918
>>>
>>> You might be interested in the following macro:
>>> ___________ #define RALLOC_ALIGN_OF(mp_type) \
>>>     offsetof( \
>>>       struct { \
>>>         char pad_RALLOC_ALIGN_OF; \
>>>         mp_type type_RALLOC_ALIGN_OF; \
>>>       }, \
>>>       type_RALLOC_ALIGN_OF \
>>>     ) ___________
>>
>> This offset gives you alignment, which you then use in
> 
> Strictly speaking, it could be an integer multiple of the alignment -
> implementations are allowed arbitrary padding between consecutive
> non-bit-field members of a struct. But it's extermely unlikely.
> 
>> RALLOC_ALIGN_UP in a way I don't understand:
>>
>>     #define RALLOC_ALIGN_UP(mp_ptr, mp_align) \
>>       ((void*)( \
>>         (((ralloc_uintptr_type)(mp_ptr)) + ((mp_align) - 1)) \
>>         & ~(((mp_align) - 1)) \
>>       ))
>>
>> Suppose mp_ptr is 5 and mp_align is 3:
>>
>>     (5 + 2) & (~2) = 111b & 101b = 101b = 5
>>
>> and 5 is not divisible by 3.  Is it supposed to work for
>> powers of two alone?
> 
> As of C2011, alignment requirements are now required to be powers of 2.

Yeah, I had power of two on the mind as well, back when I coded this 
hack. Btw, this hack can be used for interesting things.


> The committee made that decision because they couldn't find any examples
> of platforms for which that wasn't the case. 

Humm... I just used power of 2 because all of my platforms used it for 
existing alignments. That does not mean it is special, even though it is 
a prime number. ;^)



> Therefore, my lovely
> examples using types with mutually prime alignment requirements are no
> longer valid. More importantly, the issue probably never actually came
> up even when such an implementation would have been conforming.
> 

Nice.

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

#138164

On 11/18/2018 4:01 AM, Anton Shepelev wrote:
> Chris M. Thomasson:
> 
>>> https://pastebin.com/raw/f37a23918
>>
>> You might be interested in the following macro:
>> ___________ #define RALLOC_ALIGN_OF(mp_type) \
>>     offsetof( \
>>       struct { \
>>         char pad_RALLOC_ALIGN_OF; \
>>         mp_type type_RALLOC_ALIGN_OF; \
>>       }, \
>>       type_RALLOC_ALIGN_OF \
>>     ) ___________
> 
> This offset gives you alignment, which you then use in
> RALLOC_ALIGN_UP in a way I don't understand:
[...]
> Why do you treat zero size as unity in rallocex():
> 
>       if (! size) {
>         size = 1;
>       }

Iirc, to give unique pointers to the caller.


> How can its `align' argument be zero:
> 
>       if (! align) {
>         align = RALLOC_ALIGN_MAX;
>       }
> 

Just in case something called rallocex with align as zero.

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

#138092

On 11/17/18 5:08 PM, Anton Shepelev wrote:
> Richard Damon:
> 
>> In general, malloc and family will return pointers that
>> are aligned to the most strict alignment required by the
>> system.
> 
> When that is the case, I can allocate many times fewer
> single-char objects than there are free bytes in memory,
> because each separate allocation of a char effectively uses
> up the size of the largest allocation multiple.
> 

The standard basic implementation of malloc and family has an overhead
chunk added to every allocation (normally in the memory just before the
address returned), which at a minimum includes the size of the allocated
block. When it is freed, this is also used to link the free space blocks
together, and then it has the size of the free space block, and a link
to the next free space block (perhaps using some of the memory that
would be given to the user program). Due to the alignment requirements,
the blocks will have to be spaced at the maximum alignment apart.

SO yes, a call to malloc(1) will normally cost you a lot more than 1
byte off the heap. There are some version of malloc which add complexity
by putting small allocations into a separate block of memory that uses a
different allocation method, perhaps with a lot less overhead. Free can
then look at the address to figure out which pool the pointer came from.

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

#138106

Am 17.11.18 um 23:08 schrieb Anton Shepelev:
> 
> When that is the case, I can allocate many times fewer
> single-char objects than there are free bytes in memory,
> because each separate allocation of a char effectively uses
> up the size of the largest allocation multiple.
> 

Yes. But to avoid that, you could use aligned_alloc() instead (there
will still be some overhead though, just not from alignment).

Philipp

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

#138108

Anton Shepelev <anton.txt@gmail.com> writes:
>Richard Damon:
>
>> In general, malloc and family will return pointers that
>> are aligned to the most strict alignment required by the
>> system.
>
>When that is the case, I can allocate many times fewer
>single-char objects than there are free bytes in memory,
>because each separate allocation of a char effectively uses
>up the size of the largest allocation multiple.

on x86-64 and arm64 that's 16-bytes.   If you're dynamically
allocating smaller objects than that, you're doing something
wrong.

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

#138206

Richard Damon <Richard@Damon-Family.org> writes:

> In general, malloc and family will return pointers that are
> aligned to the most strict alignment required by the system.
> While it is possible that it could give less strict alignment
> for small allocations, [...]

My understanding is that such an implementation would not be
conforming.  Return values from malloc() and friends must be
suitably aligned for assignment to any pointer type, regardless
of the size of the request (including zero if the implementation
returns a non-null value in such cases).

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

#138209

On 11/23/18 9:27 PM, Tim Rentsch wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
> 
>> In general, malloc and family will return pointers that are
>> aligned to the most strict alignment required by the system.
>> While it is possible that it could give less strict alignment
>> for small allocations, [...]
> 
> My understanding is that such an implementation would not be
> conforming.  Return values from malloc() and friends must be
> suitably aligned for assignment to any pointer type, regardless
> of the size of the request (including zero if the implementation
> returns a non-null value in such cases).
> 

Many (most) implementation don't have issues with putting mis-ligned
values into pointers (that is normally only an issue with machines where
the native pointer is a 'word pointer', not a byte pointer).

The address returned needs to be able to be put into any pointer type,
but since there is no way to actually put a larger object into the
malloced memory, there is no way to actually dereference the pointer, so
the address doesn't need to be aligned well enough to actually
store/dereference types too big for the allocation.

This does depend on implementation dependent behavior, so the
implementation can only do this if it 'works' for everything the
Standard requires. A USER defined equivalent would need some extra
promises from the implementation beyond what the standard provides to do
this, but the implementation can just know that it works.

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

#138214

Richard Damon <Richard@Damon-Family.org> writes:

> On 11/23/18 9:27 PM, Tim Rentsch wrote:
>
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> In general, malloc and family will return pointers that are
>>> aligned to the most strict alignment required by the system.
>>> While it is possible that it could give less strict alignment
>>> for small allocations, [...]
>>
>> My understanding is that such an implementation would not be
>> conforming.  Return values from malloc() and friends must be
>> suitably aligned for assignment to any pointer type, regardless
>> of the size of the request (including zero if the implementation
>> returns a non-null value in such cases).
>
> Many (most) implementation don't have issues with putting mis-ligned
> values into pointers (that is normally only an issue with machines
> where the native pointer is a 'word pointer', not a byte pointer).
>
> The address returned needs to be able to be put into any pointer
> type, but since there is no way to actually put a larger object into
> the malloced memory, there is no way to actually dereference the
> pointer, so the address doesn't need to be aligned well enough to
> actually store/dereference types too big for the allocation.
>
> This does depend on implementation dependent behavior, so the
> implementation can only do this if it 'works' for everything the
> Standard requires.  A USER defined equivalent would need some extra
> promises from the implementation beyond what the standard provides
> to do this, but the implementation can just know that it works.

What I think you're saying, in effect, is that an implementation
can take advantage of undefined behavior so that we can't tell
that what it's doing makes it non-conforming.  Probably that's
right, given a sufficiently determined implementation.

On the other hand, the implementations you're talking about that
allow assignment (but not dereference) of unaligned pointers very
likely also have defined what happens in pointer-to-integer
conversions (which is implementation-defined) in such a way that
we can tell by converting the pointer to an appropriate integer
type and looking at the value in that type.  In short, converting
to an integer would let us see that a funny malloc() return value
makes the implementation non-conforming.  In practice I believe
it's hard to hide the non-conformingness, because converting to
an integer type exposes the converted pointer's alignedness (in
most implementations), and the rule for converting to an integer
type is implementation-defined, which always lets us discover
what it is.

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

#138218

On 11/24/18 3:32 AM, Tim Rentsch wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
> 
>> On 11/23/18 9:27 PM, Tim Rentsch wrote:
>>
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>>> In general, malloc and family will return pointers that are
>>>> aligned to the most strict alignment required by the system.
>>>> While it is possible that it could give less strict alignment
>>>> for small allocations, [...]
>>>
>>> My understanding is that such an implementation would not be
>>> conforming.  Return values from malloc() and friends must be
>>> suitably aligned for assignment to any pointer type, regardless
>>> of the size of the request (including zero if the implementation
>>> returns a non-null value in such cases).
>>
>> Many (most) implementation don't have issues with putting mis-ligned
>> values into pointers (that is normally only an issue with machines
>> where the native pointer is a 'word pointer', not a byte pointer).
>>
>> The address returned needs to be able to be put into any pointer
>> type, but since there is no way to actually put a larger object into
>> the malloced memory, there is no way to actually dereference the
>> pointer, so the address doesn't need to be aligned well enough to
>> actually store/dereference types too big for the allocation.
>>
>> This does depend on implementation dependent behavior, so the
>> implementation can only do this if it 'works' for everything the
>> Standard requires.  A USER defined equivalent would need some extra
>> promises from the implementation beyond what the standard provides
>> to do this, but the implementation can just know that it works.
> 
> What I think you're saying, in effect, is that an implementation
> can take advantage of undefined behavior so that we can't tell
> that what it's doing makes it non-conforming.  Probably that's
> right, given a sufficiently determined implementation.
> 
> On the other hand, the implementations you're talking about that
> allow assignment (but not dereference) of unaligned pointers very
> likely also have defined what happens in pointer-to-integer
> conversions (which is implementation-defined) in such a way that
> we can tell by converting the pointer to an appropriate integer
> type and looking at the value in that type.  In short, converting
> to an integer would let us see that a funny malloc() return value
> makes the implementation non-conforming.  In practice I believe
> it's hard to hide the non-conformingness, because converting to
> an integer type exposes the converted pointer's alignedness (in
> most implementations), and the rule for converting to an integer
> type is implementation-defined, which always lets us discover
> what it is.
> 

The specification says:

The pointer returned if the allocation succeeds is suitably aligned so
that it may be assigned to a pointer to any type of object with a
fundamental alignment requirement and then used to access such an object
or an array of such objects in the space allocated (until the space is
explicitly deallocated).

Note, it says assigned to a pointer with a fundamental alignment
requirement, and used to access such an object. It does NOT say the
value itself needs to be fundamentally aligned.

If you machine has a fundamental alignment requirement of 8 (for say
double), and you allocate 4 bytes of memory and get a results that is
only 4 byte aligned, assigning that value to a double* generally is a
safe action. The failure to be able to access the value by dereferencing
should cause a non-conformity as it is undefined behavior already as the
space can NOT point to a double value, since it is too small.

Unless you are contending that malloc(1) is required to return a memory
space big enough to hold any object of fundamental alignment (which can
include user defined structures), the smaller space seems to give the
implementation an out.

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

#138404

Richard Damon <Richard@Damon-Family.org> writes:

> On 11/24/18 3:32 AM, Tim Rentsch wrote:
>
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 11/23/18 9:27 PM, Tim Rentsch wrote:
>>>
>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>
>>>>> In general, malloc and family will return pointers that are
>>>>> aligned to the most strict alignment required by the system.
>>>>> While it is possible that it could give less strict alignment
>>>>> for small allocations, [...]
>>>>
>>>> My understanding is that such an implementation would not be
>>>> conforming.  Return values from malloc() and friends must be
>>>> suitably aligned for assignment to any pointer type, regardless
>>>> of the size of the request (including zero if the implementation
>>>> returns a non-null value in such cases).
>>>
>>> Many (most) implementation don't have issues with putting mis-ligned
>>> values into pointers (that is normally only an issue with machines
>>> where the native pointer is a 'word pointer', not a byte pointer).
>>>
>>> The address returned needs to be able to be put into any pointer
>>> type, but since there is no way to actually put a larger object into
>>> the malloced memory, there is no way to actually dereference the
>>> pointer, so the address doesn't need to be aligned well enough to
>>> actually store/dereference types too big for the allocation.
>>>
>>> This does depend on implementation dependent behavior, so the
>>> implementation can only do this if it 'works' for everything the
>>> Standard requires.  A USER defined equivalent would need some extra
>>> promises from the implementation beyond what the standard provides
>>> to do this, but the implementation can just know that it works.
>>
>> What I think you're saying, in effect, is that an implementation
>> can take advantage of undefined behavior so that we can't tell
>> that what it's doing makes it non-conforming.  Probably that's
>> right, given a sufficiently determined implementation.
>>
>> On the other hand, the implementations you're talking about that
>> allow assignment (but not dereference) of unaligned pointers very
>> likely also have defined what happens in pointer-to-integer
>> conversions (which is implementation-defined) in such a way that
>> we can tell by converting the pointer to an appropriate integer
>> type and looking at the value in that type.  In short, converting
>> to an integer would let us see that a funny malloc() return value
>> makes the implementation non-conforming.  In practice I believe
>> it's hard to hide the non-conformingness, because converting to
>> an integer type exposes the converted pointer's alignedness (in
>> most implementations), and the rule for converting to an integer
>> type is implementation-defined, which always lets us discover
>> what it is.
>
> The specification says:
>
> The pointer returned if the allocation succeeds is suitably aligned
> so that it may be assigned to a pointer to any type of object with a
> fundamental alignment requirement and then used to access such an
> object or an array of such objects in the space allocated (until the
> space is explicitly deallocated).
>
> Note, it says assigned to a pointer with a fundamental alignment
> requirement, and used to access such an object.  It does NOT say the
> value itself needs to be fundamentally aligned.
>
> If you machine has a fundamental alignment requirement of 8 (for say
> double), and you allocate 4 bytes of memory and get a results that
> is only 4 byte aligned, assigning that value to a double* generally
> is a safe action.  The failure to be able to access the value by
> dereferencing should cause a non-conformity as it is undefined
> behavior already as the space can NOT point to a double value, since
> it is too small.
>
> Unless you are contending that malloc(1) is required to return a
> memory space big enough to hold any object of fundamental alignment
> (which can include user defined structures), the smaller space seems
> to give the implementation an out.

I think the issue here is that the key phrase ("is suitably
aligned so that it may be assigned to a pointer to any type of
object" [not counting those with extended alignments]) may be
read in more than one way.  Reading one:  is aligned so that any
such conversion satisfies the requirements for defined behavior.
Reading two:  is sufficiently aligned so that the assignment
won't "blow up" in actual execution.  (I'm ignoring the matter of
access, which doesn't bear on my comments.  Also, looking back at
your comments suggests a possible third reading, about which more
further on.)

The two readings correspond to different points of view, namely,
the abstract machine in the first case and the actual machine in
the second case.  Note that the distinction is not just an as-if
scenario.  There are significant differences in what is required
under the two different points of view.  (As it turns out I wrote
a little bit of code recently that depends on the first reading,
which is what I assume was intended.)

Getting back to your earlier comment, you say "the implementation
can only do this if it 'works' for everything the Standard
requires."  I think (but am not sure) what you mean by this is
you assume the first (abstract machine) reading, but propose that
certain possibilities are allowed under the "as if" rule.  Is
that a fair statement of what you're saying?  Or do you mean some
other reading, not the same as any of the ones I have described?

I don't know if I agree that returning not-fully-aligned pointer
values (ie, that aren't "really aligned" but act like they are)
does indeed satisfy what the Standard requires.  For the sake of
discussion though let me agree for the moment.  Even if that's
true, in most implementations whether a pointer value is "really
aligned" can leak out through converting the pointer value to a
suitable integer type.  For example, in an implementation where
there is a flat, linear address space, with character addressing,
and pointer-to-integer conversion just copies the bits, it's very
easy to tell if a pointer value is appropriately aligned for a
particular type.  The example fits many if not most of the
implementations you refer to above (ie, those that don't have
issues putting mis-aligned values into pointers).  So an
implementation would need to be very restricted to be able to
operate in the manner you suggest (assuming I understand how you
are reading the key phrase, which I might not).  I don't know
of any implementation that qualifies.  Can you suggest one?

Recapping:  I assume reading one is what was intended, and that
was my (assumed) position for earlier comments.  I think reading
two is not what was intended, and allows all sorts of shenanigans,
but it does allow the "mis-aligned" behavior you proposed.  I
think your position is reading one under an-if scenario, but I'm
not sure if that's right.  So if none of these adequately captures
your views, I hope you will respond and explain them further.

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

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

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

csiph-web