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

#138077 — Pointer conversion and alignment

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'?

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.

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?

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

[toc] | [next] | [standalone]

#138078

I 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

It works by coincidence, because Standard C has no generic
pointer-to-pointer, and I shall have to work around that.

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

It must be, because:

   When a pointer to an object is converted to a pointer to
   a character type, the result points to the lowest
   addressed byte of the object. Successive increments of
   the result, up to the size of the object, yield pointers
   to the remaining bytes of the object.

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

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

#138082

Anton Shepelev <anton.txt@gmail.com> writes:

> I 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 ) );

This use confuses me.  It may be linked to what you say below.  What's
going on here?

>>    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
>
> It works by coincidence, because Standard C has no generic
> pointer-to-pointer, and I shall have to work around that.

Can you elaborate on what you see as the problem there?  C has a generic
pointer-to-object, and there's nothing stopping that object from holding
a pointer.  What do you want a generic pointer-to-pointer to be able to
do?

You need to be very strict with this sort of interface.  The fact that
the array is represented by a pointer to the data is very handy, but it
invites dangerous uses such as

  int *save = a;

After that, any use of &a that causes the data to move will invalidate
the saved pointer.

<snip>
-- 
Ben.

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

#138083

Ben Bacarisse to Anton Shepelev:

> > v = 5;
> > da_addemp( &a, &vP );
> > memcpy( vP, &v, sizeof( int ) );
>
> This use confuses me.  It may be linked to what you say
> below.  What's going on here?

Append an empty element to the dynamic array a, storing the
address of that element into the pointer vP, then store the
value 5 at that address.

> > It works by coincidence, because Standard C has no
> > generic pointer-to-pointer, and I shall have to work
> > around that.
>
> Can you elaborate on what you see as the problem there?  C
> has a generic pointer-to-object, and there's nothing
> stopping that object from holding a pointer.  What do you
> want a generic pointer-to-pointer to be able to do?

My da_* functions are declared as taking a void* as the
dynamic array, whereas in the example I am passing int**.
In order to work with dynamic arrays of any type, my
functions convert the void* argument to void**, which is not
guarranteed to work because of 6.3.2.3.7:

   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.

This is actually an interesting situation, where the return
value of a function cannot be turned into a reference
parameter.  You cannot, for example, re-express realloc() as
a procedure returning void and accepting the address of the
pointer to an allocated object:

   int* iP = malloc( sizeof( int ) );
   realloc2( &iP, 2 * sizeof( int ) );

To work around this limitation, I shall have to use a
realloc-like interface: accept the dynamic array by value
and return its new value, e.g.:

   a = da_setlen( a, 10 );

> You need to be very strict with this sort of interface.
> The fact that the array is represented by a pointer to the
> data is very handy, but it invites dangerous uses such as
>
>    int *save = a;
>
> After that, any use of &a that causes the data to move
> will invalidate the saved pointer.

That is one of the trade-offs.  You can, however, save the
reference:

   int** save = &a;

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

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

#138090

I wrote:

> My da_* functions are declared as taking a void* as the
> dynamic array, whereas in the example I am passing int**.
> In order to work with dynamic arrays of any type, my
> functions convert the void* argument to void**, which is
> not guarranteed to work because of 6.3.2.3.7:
>
>    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.

In other words, if I have allocated and int object and have
an int* pointer to it, and pass the address of that pointer
to a function as void*, is it possible to access the
allocated object from that function without the knowledge of
its type?  As far as I understand, the conversion of int**
to char** works on x86 by mere coincidence.

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

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

#138093

On 11/17/18 5:20 PM, Anton Shepelev wrote:
> I wrote:
> 
>> My da_* functions are declared as taking a void* as the
>> dynamic array, whereas in the example I am passing int**.
>> In order to work with dynamic arrays of any type, my
>> functions convert the void* argument to void**, which is
>> not guarranteed to work because of 6.3.2.3.7:
>>
>>    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.
> 
> In other words, if I have allocated and int object and have
> an int* pointer to it, and pass the address of that pointer
> to a function as void*, is it possible to access the
> allocated object from that function without the knowledge of
> its type?  As far as I understand, the conversion of int**
> to char** works on x86 by mere coincidence.
> 

When using a void * pointer to pass an address, you ALWAYS need to
convert it into the right type of pointer before using it to write into
the memory it points to. In some cases, like memcpy, it can use a
generic char type, but if you are passing the address of a pointer, in
general, to write to that pointer, you will need to know the type of the
pointer. On some machines the representation of a char* pointer (and
void *) is different than other pointers (it might not even be the same
size),

On many machines, the representation is the same, so often it will just
work if you use the wrong type, though you have technically invoked
undefined behavior. This will tend to work on machines that are byte
addressable, as on those machines all object pointers tend to be
represented the same, which does include most machines that you are
likely to encounter, but the behavior is not promised by the standard.

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

#138094

Richard Damon:

> When using a void * pointer to pass an address, you ALWAYS
> need to convert it into the right type of pointer before
> using it to write into the memory it points to. In some
> cases, like memcpy, it can use a generic char type, but if
> you are passing the address of a pointer, in general, to
> write to that pointer, you will need to know the type of
> the pointer. On some machines the representation of a
> char* pointer (and void *) is different than other
> pointers (it might not even be the same size),

Thanks for the explanation, Richard.  Since the Standard
defines pointer casts as conversions, the size of different
pointer types does not matter.  For example, char* may be of
a size different from that of int*, yet it is required to be
convertible from int* and any pointer type.  What is
important is that the Standard does not guarantee that
void** can be converted to char** (unless the underlying
object is indeed of type char).

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

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

#138095

On 11/17/18 6:32 PM, Anton Shepelev wrote:
> Richard Damon:
> 
>> When using a void * pointer to pass an address, you ALWAYS
>> need to convert it into the right type of pointer before
>> using it to write into the memory it points to. In some
>> cases, like memcpy, it can use a generic char type, but if
>> you are passing the address of a pointer, in general, to
>> write to that pointer, you will need to know the type of
>> the pointer. On some machines the representation of a
>> char* pointer (and void *) is different than other
>> pointers (it might not even be the same size),
> 
> Thanks for the explanation, Richard.  Since the Standard
> defines pointer casts as conversions, the size of different
> pointer types does not matter.  For example, char* may be of
> a size different from that of int*, yet it is required to be
> convertible from int* and any pointer type.  What is
> important is that the Standard does not guarantee that
> void** can be converted to char** (unless the underlying
> object is indeed of type char).
> 

In C, a void* pointer will freely and automatically convert to any other
type of pointer, including an int** point (which is just a pointer to an
object of type int*). Any other pointer will also freely and
automatically convert to a void* pointer.

A void** pointer is NOT a void* pointer, so this automatic conversion
doesn't apply, so if you define your routine to take a void* pointer,
and not a void** pointer, you won't need to use casts to make things
happy. It will not, unfortunately, not catch the error of forgetting the
& on the parameter.

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

#138099

Richard Damon:

> In C, a void* pointer will freely and automatically
> convert to any other type of pointer, including an int**
> point (which is just a pointer to an object of type int*).
> Any other pointer will also freely and automatically
> convert to a void* pointer.

Understood.

> A void** pointer is NOT a void* pointer, so this automatic
> conversion doesn't apply, so if you define your routine to
> take a void* pointer, and not a void** pointer, you won't
> need to use casts to make things happy.

My routines do take a void* pointer.  If they took void**
they couldn't be invoked with the address of a pointer to
integer (&a, where a is int*) as I invoke them.  The
automatic conversion of int** to void* works well, but
inside I have to access the underlying pointer (object of
type int*), which I do in a non-portable manner, by
converting from void* to char**.  As Ben has explained, one
is unlikely ever to come across a machine where it doesn't
work, but still it is not portable.

> It will not, unfortunately, not catch the error of
> forgetting the & on the parameter.

I thought about storing a "magick" byte and checking it as a
necessary condition that the parameter points to a real
dynamic array.  This dynamic type checking can be made
conditional and used in debug builds only.

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

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

#138097

Anton Shepelev <anton.txt@gmail.com> writes:

> Ben Bacarisse to Anton Shepelev:
>
>> > v = 5;
>> > da_addemp( &a, &vP );
>> > memcpy( vP, &v, sizeof( int ) );
>>
>> This use confuses me.  It may be linked to what you say
>> below.  What's going on here?
>
> Append an empty element to the dynamic array a, storing the
> address of that element into the pointer vP, then store the
> value 5 at that address.

Ah, OK.  I don't see any value in that interface since the whole point
was to have int * access.  (I'd return an index of even a void *
itself.)

>> > It works by coincidence, because Standard C has no
>> > generic pointer-to-pointer, and I shall have to work
>> > around that.
>>
>> Can you elaborate on what you see as the problem there?  C
>> has a generic pointer-to-object, and there's nothing
>> stopping that object from holding a pointer.  What do you
>> want a generic pointer-to-pointer to be able to do?
>
> My da_* functions are declared as taking a void* as the
> dynamic array, whereas in the example I am passing int**.

Ah, yes.  I see now.  I did not stop to think of the prototype.

> In order to work with dynamic arrays of any type, my
> functions convert the void* argument to void**, which is not
> guarranteed to work because of 6.3.2.3.7:
>
>    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.

I don't think this is the only problem.  I once worked on a
word-addressed machine where pointer conversions involved a bit shift.
Given your int *a; the expression (void *)a doubled the address and
converting the void * back halved it.  (It was a 16-bit word -- with a
32-bit word the value would be multiplied and divided by 4.)

Your void * argument points to an object holding an int * value and
treating that object as holding a void * will go wrong.  This is not an
alignment issue but an effective type issue.

Of course you are very unlikely to ever come across such a machine!

> This is actually an interesting situation, where the return
> value of a function cannot be turned into a reference
> parameter.  You cannot, for example, re-express realloc() as
> a procedure returning void and accepting the address of the
> pointer to an allocated object:
>
>    int* iP = malloc( sizeof( int ) );
>    realloc2( &iP, 2 * sizeof( int ) );
>
> To work around this limitation, I shall have to use a
> realloc-like interface: accept the dynamic array by value
> and return its new value, e.g.:
>
>    a = da_setlen( a, 10 );

Yes, I think you will have to do that for maximum portability.

<snip>
-- 
Ben.

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

#138100

Ben Bacarisse to Anton Shepelev:

> > v = 5;
> > da_addemp( &a, &vP );
> > memcpy( vP, &v, sizeof( int ) );
> > Append an empty element to the dynamic array a, storing
> > the address of that element into the pointer vP, then
> > store the value 5 at that address.
>
> Ah, OK.  I don't see any value in that interface since the
> whole point was to have int * access.  (I'd return an
> index of even a void * itself.)

I decided to provice such a function as a way to avoid the
passing of data through an intermediate stack variable and
to let the programmer write it directly into the array
element from some memory buffer he has.  By the way, that
same function da_addemp() returns the index of the new
element, which is discarded in the example.

> > My da_* functions are declared as taking a void* as the
> > dynamic array, whereas in the example I am passing
> > int**.
>
> Ah, yes.  I see now.  I did not stop to think of the
> prototype.

Nor did I stop to provide it...

> Your void * argument points to an object holding an int *
> value and treating that object as holding a void * will go
> wrong.  This is not an alignment issue but an effective
> type issue.

Good point.  Non-trivial pointer conversons are potentially
UB, and when they are not they are defined only with respect
to the round trip (6.3.2.3.7 in C99).  The violation of
strict aliasing, however, is another matter.

> Of course you are very unlikely to ever come across such a
> machine!

But the compiler -- why did it not optimise away my accesses
to int* objects through char** pointers even with -O5?
Probably because it didn't happen to help with performace,
which is just another coincidence.

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

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

#138101

Anton Shepelev <anton.txt@gmail.com> writes:

> Ben Bacarisse to Anton Shepelev:
>
>> > v = 5;
>> > da_addemp( &a, &vP );
>> > memcpy( vP, &v, sizeof( int ) );
>> > Append an empty element to the dynamic array a, storing
>> > the address of that element into the pointer vP, then
>> > store the value 5 at that address.
>>
>> Ah, OK.  I don't see any value in that interface since the
>> whole point was to have int * access.  (I'd return an
>> index of even a void * itself.)
>
> I decided to provice such a function as a way to avoid the
> passing of data through an intermediate stack variable and
> to let the programmer write it directly into the array
> element from some memory buffer he has.

If da_addemp returned the pointer one could write

  memcpy(da_addemp(&a), &v, sizeof v);

I'm not seeing the value of getting the pointer via another object.
Maybe it's because you want to provide the index (the current return
value) as well?

> By the way, that
> same function da_addemp() returns the index of the new
> element, which is discarded in the example.

Ah, right.  Mind you, thinking it over, a void * might be better.  I'm
the sort of programmer who'd be tempted to write

  a[da_addamp(&a, ...)] = 42;

which is not safe!

<snip>
> But the compiler -- why did it not optimise away my accesses
> to int* objects through char** pointers even with -O5?

Sorry, I'm not sure what that's about.  Did you post an example?  If so,
I must have missed it.  (Did you mean -Ofast rather than -O5?)

> Probably because it didn't happen to help with performace,
> which is just another coincidence.

Probably.

-- 
Ben.

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

#138104

Ben Bacarisse:

> If da_addemp returned the pointer one could write
>
>    memcpy(da_addemp(&a), &v, sizeof v);
>
> I'm not seeing the value of getting the pointer via
> another object.  Maybe it's because you want to provide
> the index (the current return value) as well?

Yes.  Also, in production code one shall check for error
before invoking memcpy().

> I'm the sort of programmer who'd be tempted to write
>
>    a[da_addamp(&a, ...)] = 42;
>
> which is not safe!

Well are you bold!  I try not to mix expressions with side
effects.

> > But the compiler -- why did it not optimise away my
> > accesses to int* objects through char** pointers even
> > with -O5?
>
> Sorry, I'm not sure what that's about.  Did you post an
> example?  If so, I must have missed it.  (Did you mean
> -Ofast rather than -O5?)

-O5 in GCC.  I didn't know it accepted any non-negative
integer with the -O option.  I have changed it to -O3 now.
My code:

   dynarray.h: https://pastebin.com/raw/VYFG3gBS
   dynarray.c: https://pastebin.com/raw/DQCEWgrH
   da_test.c : https://pastebin.com/raw/vMmq8NKJ

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

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

#138107

Anton Shepelev <anton.txt@gmail.com> writes:

> Ben Bacarisse:
>
>> If da_addemp returned the pointer one could write
>>
>>    memcpy(da_addemp(&a), &v, sizeof v);
>>
>> I'm not seeing the value of getting the pointer via
>> another object.  Maybe it's because you want to provide
>> the index (the current return value) as well?
>
> Yes.  Also, in production code one shall check for error
> before invoking memcpy().

Sure, but that alone does not explain the preference for a void **
argument rather than a void * return.  I get that you want to return
something else and with error-checking you need another local variable
anyway, but I have a mysterious dislike for values returned through
pointer arguments.

>> I'm the sort of programmer who'd be tempted to write
>>
>>    a[da_addemp(&a, ...)] = 42;
>>
>> which is not safe!
>
> Well are you bold!  I try not to mix expressions with side
> effects.

So do I.  The point is that the side effect is not explicit.  Anyway,
error checking would avoid this problem in most situations:

  int i = da_addemp(&a, ...);
  if (i >= 0)
     a[i] = 42;

<snip>
-- 
Ben.

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

#138109

Ben Bacarisse:

> Sure, but that alone does not explain the preference for a
> void ** argument rather than a void * return.  I get that
> you want to return something else and with error-checking
> you need another local variable anyway, but I have a
> mysterious dislike for values returned through pointer
> arguments.

I will return the pointer to the (potentially) reallocated
dynamic array, and make that null in case of error.  I must
do for portability and strict aliasing, anyway.

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

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

#138085

Ben Bacarisse to Anton Shepelev:

> What do you want a generic pointer-to-pointer to be able
> to do?

This:
http://www.iso-9899.info/wiki/Generic_Pointer_To_Pointer

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

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

#138079

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.
However the standard does not guarantee it. I think there is a definition
for strictest type in the latest standard to get round this problem.

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

#138081

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.

-- 
Ian.

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

#138084

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 long and intmax_t were added in C99, so if you need to target
pre-C99 implementations you can check __STDC_VERSION__.

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

#138086

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.
However there's no agreement on what long double should be.

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

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

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

csiph-web