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

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

Dymamic arrays: memory management and naming

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

Contents

  Dymamic arrays: memory management and naming Anton Shepelev <anton.txt@gmail.moc> - 2023-09-09 13:23 +0300
    Re: Dymamic arrays: memory management and naming Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-09 03:56 -0700
    Re: Dymamic arrays: memory management and naming Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 15:06 +0000
    Re: Dymamic arrays: memory management and naming scott@slp53.sl.home (Scott Lurndal) - 2023-09-09 15:44 +0000
    Re: Dymamic arrays: memory management and naming Spiros Bousbouras <spibou@gmail.com> - 2023-09-10 17:57 +0000
      Re: Dymamic arrays: memory management and naming Anton Shepelev <anton.txt@gmail.moc> - 2023-09-10 23:49 +0300
        Re: Dymamic arrays: memory management and naming Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-10 21:25 +0000
    Re: Dymamic arrays: memory management and naming Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-12 16:07 -0700
      Re: Dymamic arrays: memory management and naming Anton Shepelev <anton.txt@gmail.moc> - 2023-09-17 00:44 +0300
    Re: Dymamic arrays: memory management and naming Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-17 16:51 -0700
      Re: Dymamic arrays: memory management and naming Anton Shepelev <anton.txt@gmail.moc> - 2023-09-19 01:10 +0300
        Re: Dymamic arrays: memory management and naming Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-19 07:58 -0700
        Re: Dymamic arrays: memory management and naming Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-19 10:33 -0700
          Re: Dymamic arrays: memory management and naming Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-19 15:08 -0700
            Re: Dymamic arrays: memory management and naming "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 15:35 -0700
            Re: Dymamic arrays: memory management and naming Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-19 22:49 +0000
              Re: Dymamic arrays: memory management and naming Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-19 22:30 -0700
                Re: Dymamic arrays: memory management and naming Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-20 02:46 -0700
                  Re: Dymamic arrays: memory management and naming Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-20 07:06 -0700
                Re: Dymamic arrays: memory management and naming Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-20 21:03 +0000
                  Re: Dymamic arrays: memory management and naming Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-25 14:08 -0700
                    Re: Dymamic arrays: memory management and naming Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-25 21:27 +0000
            Re: Dymamic arrays: memory management and naming Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-19 22:17 -0700
          Re: Dymamic arrays: memory management and naming Anton Shepelev <anton.txt@gmail.moc> - 2023-09-24 00:39 +0300
            Re: Dymamic arrays: memory management and naming Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2023-09-23 21:48 +0000
            Re: Dymamic arrays: memory management and naming James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-24 00:15 -0400
            Re: Dymamic arrays: memory management and naming Spiros Bousbouras <spibou@gmail.com> - 2023-09-24 11:48 +0000
              Re: Dymamic arrays: memory management and naming Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-24 16:08 +0000
                Re: Dymamic arrays: memory management and naming Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-25 13:21 -0700
                  Re: Dymamic arrays: memory management and naming Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-25 21:06 +0000
                    Re: Dymamic arrays: memory management and naming Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-25 18:43 -0700
                Re: Dymamic arrays: memory management and naming Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-25 23:14 +0000
                  Re: Dymamic arrays: memory management and naming Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-25 19:00 -0700
                    Re: Dymamic arrays: memory management and naming Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-26 02:38 +0000
                      Re: Dymamic arrays: memory management and naming Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-25 23:42 -0700
                    Re: Dymamic arrays: memory management and naming Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-25 19:38 -0700
                      Re: Dymamic arrays: memory management and naming Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-25 23:41 -0700
                        Re: Dymamic arrays: memory management and naming Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-26 02:42 -0700
                          Re: Dymamic arrays: memory management and naming Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-03 03:29 -0700
              Re: Dymamic arrays: memory management and naming Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-24 16:11 +0000
              Re: Dymamic arrays: memory management and naming James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-24 12:28 -0400
                Re: Dymamic arrays: memory management and naming Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-24 17:10 +0000
                  Re: Dymamic arrays: memory management and naming James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-24 13:56 -0400
              Re: Dymamic arrays: memory management and naming Phil Carmody <pc+usenet@asdf.org> - 2023-09-30 13:50 +0300
                Re: Dymamic arrays: memory management and naming Spiros Bousbouras <spibou@gmail.com> - 2023-10-01 17:43 +0000
            Re: Dymamic arrays: memory management and naming Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-25 09:21 -0700
              Re: Dymamic arrays: memory management and naming Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-25 18:06 +0000
                Re: Dymamic arrays: memory management and naming Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-25 15:24 -0700
                  Re: Dymamic arrays: memory management and naming Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-25 23:49 +0000
                  Re: Dymamic arrays: memory management and naming Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-26 00:07 +0000

Page 3 of 3 — ← Prev page 1 2 [3]

#176310

On 9/24/23 07:48, Spiros Bousbouras wrote:
> On Sun, 24 Sep 2023 00:39:15 +0300
> Anton Shepelev <anton.txt@gmail.moc> wrote:
>> Futhermore, some systems seem not to require alignment,
>> e.g.:
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> void print_as( char const * data )
>> { for( int i = 0; i < 2; i += 1 )
>> { printf( "%i ", *((short*)(data+i*2)) ); }
>
> %hi would be more precise than %i .At the very least it saves the reader
> the trouble of trying to collect from the various points in the standard
> the information to decide whether just %i is also guaranteed to work.

Just in case you wanted to know, here's the relevant sections:
"i The int argument ..." (7.19.6.1p8), which tells you that the argument
that corresponds to %i must be an int.

"If an int can represent all values of the original type, the value is
converted to an int; otherwise, it is converted to an unsigned int."
(6.3.1.1p2). Since all values representable as a short are also
representable as an int, short is always promoted to an int.

As a result, for printf(), "%hi" means the same thing as "%i"; it was
added solely for the purpose of allowing the same format string to be
used with both the printf family and the scanf family of functions.

>> printf("\n");
>> }
>>
>> int main()
>> { char* const data = malloc(5);
>> for( int i = 0; i < 5; i += 1 )
>> { data[i] = (char)i%2; }
>
> (char)i will be promoted to something else (most likely int) before the


Correct. It will normally be an int, unless CHAR_MAX > INT_MAX, in which
case char will promote to to unsigned int. That is possible only if char
is unsigned, and CHAR_BIT >= 16 (which does happen, but it's pretty
uncommon).

> % operation takes place so the cast is pointless. Even if you had written
> (char)(i%2) , given the values involved I don't see the point.

And, after being promoted to int or unsigned int, it will be converted
back to char.

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

#176313

On 2023-09-24, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> As a result, for printf(), "%hi" means the same thing as "%i"; it was
> added solely for the purpose of allowing the same format string to be
> used with both the printf family and the scanf family of functions.

It isn't the same.  The h means that, internally, printf converts the
int argument value to short.

Thus, we cannot expect the correct decimal representation of INT_MAX
using printf("%hi\n", INT_MAX).

When used with d or i, h means "show me the implementation-defined
value when we truncate the argument to short".

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

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

#176321

On 9/24/23 13:10, Kaz Kylheku wrote:
> On 2023-09-24, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> As a result, for printf(), "%hi" means the same thing as "%i"; it was
>> added solely for the purpose of allowing the same format string to be
>> used with both the printf family and the scanf family of functions.
>
> It isn't the same. The h means that, internally, printf converts the
> int argument value to short.

I meant that it is the same when passing a short argument. Sorry for not
being sufficiently specific.

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

#176792

Spiros Bousbouras <spibou@gmail.com> writes:
> On Sun, 24 Sep 2023 00:39:15 +0300
> Anton Shepelev <anton.txt@gmail.moc> wrote:
>>       for( int i = 0; i < 5; i += 1 )
>>       {  data[i] = (char)i%2;  }
>
> (char)i  will be promoted to something else (most likely  int)  before the
> %  operation takes place so the cast is pointless. Even if you had written
> (char)(i%2) , given the values involved I don't see the point.

Would you have made the same argument had the '2' been a '3' and the '5'
been an unknown value? The defensive coder in me sees almost all
constants as a possibly having alternative values.

Phil
-- 
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

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

#176877

On Sat, 30 Sep 2023 13:50:51 +0300
Phil Carmody <pc+usenet@asdf.org> wrote:
> Spiros Bousbouras <spibou@gmail.com> writes:
> > On Sun, 24 Sep 2023 00:39:15 +0300
> > Anton Shepelev <anton.txt@gmail.moc> wrote:
> >>       for( int i = 0; i < 5; i += 1 )
> >>       {  data[i] = (char)i%2;  }
> >
> > (char)i  will be promoted to something else (most likely  int)  before the
> > %  operation takes place so the cast is pointless. Even if you had written
> > (char)(i%2) , given the values involved I don't see the point.
> 
> Would you have made the same argument had the '2' been a '3' and the '5'
> been an unknown value?

The  2  being a  3  would have made no difference to my points. 5  being some
other value would depend on what restrictions we would have about the set of
possible values. One needs some restrictions to be able to programme at all ,
even knowing that the possible value is an integer is also a restriction.

> The defensive coder in me sees almost all
> constants as a possibly having alternative values.

Prudent coding is also not placing undue burden on one's mental faculties : if
no obvious generalisation suggests itself then don't try to invent one. For
a kind of extreme anti-generalisation attitude I offer the following from the
inventor of Forth :

I do not have a piece of software that will handle N pin chips, even where N
is between 40 and 84. I have three versions each is specialized. To add the
code necessary to change the number of output pads is certainly possible. But
I don't need to solve the general problem when I only have to solve these
specific cases.

  Chuck Moore
  http://www.ultratechnology.com/tape1-2.htm

-- 
vlaho.ninja/prog

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

#176369

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

> Tim Rentsch:
>
>> One further thought...
>>
>> As of C11, there is a type max_align_t, defined in
>> <stddef.h>, whose alignment is the maximum alignment
>> supported by the implementation.  The grain size for
>> allocation should be a multiple of
>>
>>     _Alignof (max_align_t)
>>
>> so this alignment can be supported.  Also, the amount of
>> space you use for your "pre-array" metadata should be
>> chosen to be a multiple of _Alignof (max_align_t),
>> otherwise the array alignments might be off in some cases.
>
> [...] Yes, I have discussed this issue here before, and
> implemented a (I think Ben's) suggestion to calculate the
> negative offset as the size of the metadata structure
> rounded up to a power of two, which should ensure correct
> alignment in most cases.

Sometimes this technique will use too much space, and sometimes
too little.  It's better to use a method that always works, if
one is available.

> Futhermore, some systems seem not to require alignment,
> [example removed]

It can happen that an implmentation doesn't need alignment on
some types but does need it on others.  Moreover you want the
code that you write to be portable, so it's necessary to assume
that alignment requirements are in force.

In your particular case, a nice way to do it is as part of the
type definition for the array prefix metadata (I've forgotten
what you called it; here it is Header, and for expository reasons
I chose longer names for the structure members):

    #include <stddef.h>

    #define ALIGN_MAX   _Alignas (max_align_t)

    typedef struct {
                    size_t   first_unused;
                    size_t   total_available;
                    size_t   element_size;
        ALIGN_MAX     char   data[];
    } Header;

Given this definition for the prefix metadata, there are simple
definitions for META() and DATA(), as follows:

    Header *
    META( void *elements ){
        char *data = elements;
        return  data ? (Header*) (data - offsetof( Header, data )) : NULL;
    }

    void *
    DATA( Header *h ){
        return  h ? h->data : NULL;
    }

This approach provides just what you need, if C11 is available.

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

#176378

On 2023-09-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>     #include <stddef.h>
>
>     #define ALIGN_MAX   _Alignas (max_align_t)
>
>     typedef struct {
>                     size_t   first_unused;
>                     size_t   total_available;
>                     size_t   element_size;
>         ALIGN_MAX     char   data[];
>     } Header;
>
> Given this definition for the prefix metadata, there are simple
> definitions for META() and DATA(), as follows:
>
>     Header *
>     META( void *elements ){
>         char *data = elements;
>         return  data ? (Header*) (data - offsetof( Header, data )) : NULL;
>     }
>
>     void *
>     DATA( Header *h ){
>         return  h ? h->data : NULL;
>     }

How about:

   typedef ALIGN_MAX struct {
       size_t   first_unused;
       size_t   total_available;
       size_t   element_size;
   } Header;

   Header *
   META(void *elements) {
      return elements ? (Header *) elements - 1 : NULL;
   }

   void *
   DATA(Header *h) {
      return  h ? h + 1 : NULL;
   }

Can't we have ALIGN_MAX on the struct type, like with
__attribute__((aligned))?

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

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

#176393

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-09-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>>     #include <stddef.h>
>>
>>     #define ALIGN_MAX   _Alignas (max_align_t)
>>
>>     typedef struct {
>>                     size_t   first_unused;
>>                     size_t   total_available;
>>                     size_t   element_size;
>>         ALIGN_MAX     char   data[];
>>     } Header;
>>
>> Given this definition for the prefix metadata, there are simple
>> definitions for META() and DATA(), as follows:
>>
>>     Header *
>>     META( void *elements ){
>>         char *data = elements;
>>         return  data ? (Header*) (data - offsetof( Header, data )) : NULL;
>>     }
>>
>>     void *
>>     DATA( Header *h ){
>>         return  h ? h->data : NULL;
>>     }
>
> How about:
>
>    typedef ALIGN_MAX struct {
>        size_t   first_unused;
>        size_t   total_available;
>        size_t   element_size;
>    } Header;
>
>    Header *
>    META(void *elements) {
>       return elements ? (Header *) elements - 1 : NULL;
>    }
>
>    void *
>    DATA(Header *h) {
>       return  h ? h + 1 : NULL;
>    }
>
> Can't we have ALIGN_MAX on the struct type, like with
> __attribute__((aligned))?

Please find something better to do than post these
useless responses.  I don't want to waste any more
time on them.

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

#176405

On 2023-09-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> Can't we have ALIGN_MAX on the struct type, like with
>> __attribute__((aligned))?
>
> Please find something better to do than post these
> useless responses.  I don't want to waste any more
  ^^^^^^^

Thanks for the hint; that informs me there is something wrong with it.

Indeed, _Alignas cannot be used that way, due to a constraint:

"The _Alignas specifier shall not be used in conjunction with either of
the storage class specifiers typedef or register." [N3096 6.7.5]

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

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

#176406

On 2023-09-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> Can't we have ALIGN_MAX on the struct type, like with
>> __attribute__((aligned))?
>
> Please find something better to do than post these
> useless responses.  I don't want to waste any more
> time on them.

Aha! I got it: let's take all the members of Header and wrap them into an
anonymous struct member. Then, put the _Alignas onto that member.

#include <stddef.h>

#define ALIGN_MAX   _Alignas (max_align_t)

typedef struct {
   ALIGN_MAX struct {
       size_t   first_unused;
       size_t   total_available;
       size_t   element_size;
   };
} Header;

Header *
META(void *elements) {
   return elements ? (Header *) elements - 1 : NULL;
}

void *
DATA(Header *h) {
   return  h ? h + 1 : NULL;
}

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web