Hello, all

I have decided to publish my implementaton of dymanic arrays
that you helped me with back in 2018[1] (time rolls like a
steamroller). The initial version will have a single built-
in memory-management strategy, and I ask your opinion about
one based on a fixed Fibonacci progerssion, so that the
array size in bytes grows as: 1,2,3,5,8,13,... And of course
it may start with any Fibonacci number if required. The
purpose is to let the memory manager re-use the two previous
adjacent allocations for the next one without any gaps.

The fixed sizes help unify memory usage between different
dymamic arrays. Do you think it worth the effort, or is a
simple 1.5 growth factor relative to whatever the current
capacity the array has better on the whole, in that it has a
much higher ratio of efficiency to code complexity, for the
Fibonacci approach will require the storage of the previous
capacity and a lookup algorithm for cases when the
programmer sets the array length explicitly (so that a
request of 12 bytes results in a 13-byte allocation).

Another question is function names. The current ones use
the `da_' prefix:

void* da_new ( size_t elem_sz ); /* create an array */
void* da_newl ( size_t elem_sz, unsigned int len ); /* of specified length */
void* da_setlen( void * a , unsigned int len ); /* set the length */
int da_len ( void * a ); /* get the length */
void* da_add ( void * a , void * data_p ); /* add an element */
void* da_addemp( void * a , void ** elem_pp ); /* add an empty element */
/* ..and provide its address for writing */
void da_free ( void * a ); /* deallocate */

Do you think the `a_' prefix would incur a significant risk
of name collisions?
____________________
1. In two threads:
<20181117143819.43938ee34006bbcc1826bf0c@gmail.com>
<20181119022614.5cf93af72a29cb41cdc86910@gmail.com>

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On Saturday, 9 September 2023 at 11:23:51 UTC+1, Anton Shepelev wrote:
> Hello, all
>
> I have decided to publish my implementaton of dymanic arrays
> that you helped me with back in 2018[1] (time rolls like a
> steamroller). The initial version will have a single built-
> in memory-management strategy, and I ask your opinion about
> one based on a fixed Fibonacci progerssion, so that the
> array size in bytes grows as: 1,2,3,5,8,13,... And of course
> it may start with any Fibonacci number if required. The
> purpose is to let the memory manager re-use the two previous
> adjacent allocations for the next one without any gaps.
>
> The fixed sizes help unify memory usage between different
> dymamic arrays. Do you think it worth the effort, or is a
> simple 1.5 growth factor relative to whatever the current
> capacity the array has better on the whole, in that it has a
> much higher ratio of efficiency to code complexity, for the
> Fibonacci approach will require the storage of the previous
> capacity and a lookup algorithm for cases when the
> programmer sets the array length explicitly (so that a
> request of 12 bytes results in a 13-byte allocation).
>
> Another question is function names. The current ones use
> the `da_' prefix:
>
> void* da_new ( size_t elem_sz ); /* create an array */
> void* da_newl ( size_t elem_sz, unsigned int len ); /* of specified length */
> void* da_setlen( void * a , unsigned int len ); /* set the length */
> int da_len ( void * a ); /* get the length */
> void* da_add ( void * a , void * data_p ); /* add an element */
> void* da_addemp( void * a , void ** elem_pp ); /* add an empty element */
> /* ..and provide its address for writing */
> void da_free ( void * a ); /* deallocate */
>
> Do you think the `a_' prefix would incur a significant risk
> of name collisions?
> ____________________
> 1. In two threads:
> <20181117143819.4393...@gmail.com>
> <20181119022614.5cf9...@gmail.com>
>
I strongly suspect that array lengths have a statistical distribution such that
the Fibonacci sequence provides the best prediction of eventual length
given current length.
We know that 1.5 works reasonably well, and phi is 1.618, which isn't too
far off.
How you'd prove that I'm not sure.

On 2023-09-09, Anton Shepelev <anton.txt@gmail.moc> wrote:
> Do you think the `a_' prefix would incur a significant risk
> of name collisions?

That risk is something that only becomes real when your library
is actually used. So I wouldn't worry about it, and concentrate
on getting the library used.

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

Anton Shepelev <anton.txt@gmail.moc> writes:
>Hello, all
>
>I have decided to publish my implementaton of dymanic arrays

Dymanic?

"showing wild, apparently deranged, excitement and energy."?

On Sat, 9 Sep 2023 13:23:36 +0300
Anton Shepelev <anton.txt@gmail.moc> wrote:
> Hello, all
>
> I have decided to publish my implementaton of dymanic arrays
> that you helped me with back in 2018[1] (time rolls like a
> steamroller). The initial version will have a single built-
> in memory-management strategy, and I ask your opinion about
> one based on a fixed Fibonacci progerssion, so that the
> array size in bytes grows as: 1,2,3,5,8,13,... And of course
> it may start with any Fibonacci number if required. The
> purpose is to let the memory manager re-use the two previous
> adjacent allocations for the next one without any gaps.
>
> The fixed sizes help unify memory usage between different
> dymamic arrays. Do you think it worth the effort, or is a
> simple 1.5 growth factor relative to whatever the current
> capacity the array has better on the whole, in that it has a
> much higher ratio of efficiency to code complexity, for the
> Fibonacci approach will require the storage of the previous
> capacity and a lookup algorithm for cases when the
> programmer sets the array length explicitly (so that a
> request of 12 bytes results in a 13-byte allocation).

It is worth it for the originality factor , if nothing else ! I assume the
code will be open source and fairly small so if the user doesn't like it ,
he/she can always change it.

> Another question is function names. The current ones use
> the `da_' prefix:
>
> void* da_new ( size_t elem_sz ); /* create an array */
> void* da_newl ( size_t elem_sz, unsigned int len ); /* of specified length */
> void* da_setlen( void * a , unsigned int len ); /* set the length */
> int da_len ( void * a ); /* get the length */
> void* da_add ( void * a , void * data_p ); /* add an element */
> void* da_addemp( void * a , void ** elem_pp ); /* add an empty element */
> /* ..and provide its address for writing */
> void da_free ( void * a ); /* deallocate */
>
> Do you think the `a_' prefix would incur a significant risk
> of name collisions?

I wouldn't worry about it. Again , if it doesn't work for the user , they
can change it. Personally I would choose something more mnemonic like
dyna_ .

> 1. In two threads:
> <20181117143819.43938ee34006bbcc1826bf0c@gmail.com>
> <20181119022614.5cf93af72a29cb41cdc86910@gmail.com>

Spiros Bousbouras to Anton Shepelev:

> > The initial version will have a single built- in memory-
> > management strategy, and I ask your opinion about one
> > based on a fixed Fibonacci progerssion
>
> It is worth it for the originality factor , if nothing
> else ! I assume the code will be open source and fairly
> small so if the user doesn't like it , he/she can always
> change it.

Well, I have decided to follow Kaz's advice and publish the
simplest think that works. Then I will add support for
custom allocation strategies and provide the Fibonacci one
as an option.

> > Do you think the `a_' prefix would incur a significant
> > risk of name collisions?
>
> I wouldn't worry about it. Again , if it doesn't work for
> the user , they can change it.

The ability to use third-party code as-is is an advantage.

> Personally I would choose something more mnemonic like
> dyna_ .

I suppose that whoever decides to use my library will use it
intensively, because dynamic arrays are a very fundamental
and highly-demanded data-structure, and my principle is to
make indentifier length inversely proportinal to use
frequency, so I will start with `a_' and will consider a) a
custom prefix specifiable via a macro and b) global
structure with function pointers, so that the user may
"import" it into his code under whatever name he please,
somewhat similar to the import facilities in Modula, Python,
and Javascript.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On 2023-09-10, Anton Shepelev <anton.txt@gmail.moc> wrote:
>> I wouldn't worry about it. Again , if it doesn't work for
>> the user , they can change it.
>
> The ability to use third-party code as-is is an advantage.

A clash does not always mean that a user has to edit your
code.

If the user's program is not actually using the clashing identifier
(they are only using yours, not the unrelated other one coming from
somewhere), they can use #define to rename it out of the way.

#define is so effective that you can take C code which uses identifiers
like "class" and "new" and make it compile as C++ without renaming
those symbols in the code.

If you're converting the code to C++ which uses "class"
and "new", then you can't do that.

In the TXR project, I use the #define trick to work around
a few cases of identifier pollution from system headers.

This is needed only on BSD systems and derivatives,
which have broken feature selection.

The ./configure script detects whether the clashes are present and for
the symbols in question it emits #define renames, deposited into
config.h.

One example is the identifier "mergesort". That comes from some BSD
header in such a way that I can't disable it without losing some
needed declarations. I happen to have a function called "mergesort",
which I'm reluctant to rename; why should i?

The configure script detects that, adds #define mergesort txr_mergesort
and all is well.

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

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

> I have decided to publish my implementaton of dymanic arrays
> [...] The initial version will have a single built-
> in memory-management strategy, and I ask your opinion about
> one based on a fixed Fibonacci progerssion, so that the
> array size in bytes grows as: 1,2,3,5,8,13,... [...]
>
> Do you think it worth the effort, or is a
> simple 1.5 growth factor [...] better on the whole, [...]
>
> Another question is function names. The current ones use
> the `da_' prefix [is a simpler 'a_' prefix okay instead?]

My reactions/comments/suggestions, for what they are worth:

One: simpler is better. I am skeptical that the complications
of using Fibonacci sizes will be worth the effort.

Two: my intuition says that a fixed growth factor has issues
when considered over a large range of sizes. I tend to favor a
larger growth factor (eg, 2x) for small sizes and a smaller
growth factor (eg, + size/4 or even + size/16) for very large
sizes, with a 1.5 growth factor in between. How many steps
there are and where the transitions should be is up to you.

Three: personally I think the 'da_' prefix is a better choice
than the shorter 'a_' prefix. No basis for that suggestion, just
a gut reaction.

Tim Rentsch:

> my intuition says that a fixed growth factor has issues
> when considered over a large range of sizes. I tend to
> favor a larger growth factor (eg, 2x) for small sizes and
> a smaller growth factor (eg, + size/4 or even + size/16)
> for very large sizes, with a 1.5 growth factor in between.

I will remember your suggestion, in order later to implement
it as a custom growth strategy with the growth factor
determined by sigmoid function of array size, startng with a
large value and asymptotically converging to a smaller one.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

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

> Hello, all
>
> I have decided to publish my implementaton of dymanic arrays
> that you helped me with back in 2018[1] (time rolls like a
> steamroller). The initial version will have a single built-
> in memory-management strategy, and I ask your opinion about
> one based on a fixed Fibonacci progerssion, so that the
> array size in bytes grows as: 1,2,3,5,8,13,... [...]

Another point to consider: if you are using malloc(), and
the array elements might be small (eg chars or shorts), you
might try to take into account minimum allocation size,
grain, and overhead. Here is a program to help explain:

#include <stdio.h>
#include <stdlib.h>

int
main(){
enum { N = 90 };
char *blocks[N+1];
unsigned i;
for( i = 0; i < N+1; i++ ){
blocks[i] = malloc( i );
}
for( i = 0; i < N; i++ ){
printf( "i: %2u delta: %3td\n", i, blocks[i+1] - blocks[i] );
}
}

Running this program on my system here, it indicates a grain
of 16 bytes, an overhead of 8 bytes, and a minimum allocation
size of 24 bytes. That is, any allocation of 24 bytes or less
is the same as asking for 24 bytes, and any larger requests
add 8 and then round up to a multiple of 16 (so asking for 40
bytes uses 48 of memory, asking for 41 bytes uses 64 bytes of
memory, etc). Adjusting the choice of growth amount to take
these factors into account should give more efficient use of
memory (as mentioned, for small element sizes). Note that the
various parameters can be determined dynamically at startup,
so they don't need to be hard coded or anything like that.

(Yes I know this program has undefined behavior. Despite that
it is still useful.)

Tim Rentsch:

> Another point to consider: if you are using malloc(), and
> the array elements might be small (eg chars or shorts),

I thought such effects should be prominent only with small
array elements /and/ small array lengthes... I expected them
to drown below the noise floor (so to say) when the length
becomes large.

> you
> might try to take into account minimum allocation size,
> grain, and overhead. Here is a program to help explain:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int
> main(){
> enum { N = 90 };
> char *blocks[N+1];
> unsigned i;
> for( i = 0; i < N+1; i++ ){
> blocks[i] = malloc( i );
> }
> for( i = 0; i < N; i++ ){
> printf( "i: %2u delta: %3td0, i, blocks[i+1] - blocks[i] );
> }
> }
>
> Running this program on my system here, it indicates a grain
> of 16 bytes, an overhead of 8 bytes

Same here (on the Freeshell.de server). I had not thought
of that at all, assuming subconsicously that the allocation
map (some sort of RAM filesystem) is kept separately from
the actual allocated blocks. May I rely on the
contiguousness of each overhead data element with the
corresponding allocated block of data? May I rely in
general on the sequential order of allocations that your
program clearly demonstrated in both our cases? For aught I
know, the memory manager is free to do howsoever it wishes...

Thanks for the observation, Tim. As you see, it is somewhat
below the horison (gelogically speaking) of my knowledge.
If you should care to provide a strategy that estimates
these parameters of the memory manager and then uses them to
optimise the allocation of dynamic arrays, I shall gladly
include it as as an option with my implementation. Right now
I am casting for some lean, clean, and not git-driven platform
to host the code.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

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

> Tim Rentsch:
>
>> Another point to consider: if you are using malloc(), and
>> the array elements might be small (eg chars or shorts),
>
> I thought such effects should be prominent only with small
> array elements /and/ small array lengthes... I expected them
> to drown below the noise floor (so to say) when the length
> becomes large.

I think it's not as simple as that. Consider a scenario: a
program is making use of a growable character buffer, with
eventually 150 bytes needed. Let's take an initial guess of 8
elements, and growing by a factor of two. The chain of events in
the two cases would look like

(ignore grain, etc) 8 16 32 64 128 256 (272 used)
(factor in grain, etc) 24 56 120 248 (256 used)

Taking granularity, etc, into account the program needs just four
allocations (and uses only slightly less memory). Ignoring these
factors the program needs six allocations. Granted, the memory
savings is only about 6 percent, but there is also a time savings
by virtue of needing fewer re-allocations.

(If the numbers in the second line are confusing, remember that
at each stage the numbers are rounded up to be 8 mod 16. The
initial 24 is because that's the smallest amount of memory that
the allocator will fit in a single block; any smaller amount
will end up returning 24 usable bytes, so we might as well ask
for that.)

I admit this is only one scenario, and other scenarios will give
different results, including some where a naive approach does
better. Still, the potential upside seems worth getting, since
the cost of getting it (basically some simple arithmetic in the
allocation function) is pretty small.

>> you
>> might try to take into account minimum allocation size,
>> grain, and overhead. Here is a program to help explain:
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int
>> main(){
>> enum { N = 90 };
>> char *blocks[N+1];
>> unsigned i;
>> for( i = 0; i < N+1; i++ ){
>> blocks[i] = malloc( i );
>> }
>> for( i = 0; i < N; i++ ){
>> printf( "i: %2u delta: %3td0, i, blocks[i+1] - blocks[i] );
>> }
>> }
>>
>> Running this program on my system here, it indicates a grain
>> of 16 bytes, an overhead of 8 bytes
>
> Same here (on the Freeshell.de server). I had not thought
> of that at all, assuming subconsciously that the allocation
> map (some sort of RAM filesystem) is kept separately from
> the actual allocated blocks. May I rely on the
> contiguousness of each overhead data element with the
> corresponding allocated block of data?

I think most allocators use a little bit of memory just before
each allocated block, to facilitate free()-ing and coalescing of
adjacent free blocks. That isn't guaranteed of course, but it's
common.

> May I rely in
> general on the sequential order of allocations that your
> program clearly demonstrated in both our cases?

When a program starts it's likely that the allocator has a single
large block of memory available, and will fill successive calls
at one end of that block. Again, not guaranteed, but I expect
it occurs often enough that it's worth making a stab.

If an attempt to discover the allocator characteristics fails, I
think a reasonable fallback is to guess a granularity of 16 and
an overhead of 8 (minimum size 24) for 64-bit systems, and half
of those for 32-bit systems.

> For aught I
> know, the memory manager is free to do howsoever it wishes...

Certainly it is, but it's not just a coincidence that the
numbers you got match the numbers that I got.

Having said that, I should add that my experience with MS Windows
is that it has enormous amount of overhead for each allocated
block.

> Thanks for the observation, Tim. As you see, it is somewhat
> below the horizon (geologically speaking) of my knowledge.
> If you should care to provide a strategy that estimates
> these parameters of the memory manager and then uses them to
> optimise the allocation of dynamic arrays, I shall gladly
> include it as as an option with my implementation. Right now
> I am casting for some lean, clean, and not git-driven platform
> to host the code.

My first suggestion is to provide an option (runtime selectable)
that guesses 'sizeof (size_t)' for overhead, twice that for the
granularity, and three times that for the minimum request size.
It's probably worth adding an initialization call to your
allocator interface, so that you can later add code that tries to
discover the true values of these parameters.

(Note: some spelling corrections to your message have been
made.)

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

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.

Note by the way that sizeof (max_align_t) might not be the same
as _Alignof (max_align_t).

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> Note by the way that sizeof (max_align_t) might not be the same
> as _Alignof (max_align_t).

Indeed. I was curious about this, so I wrote a small test program that
shows that _Alignof (max_align_t) is 16, but sizeof (max_align_t) is 32
on the implementation I'm using.

I'm using gcc, which defines max_align_t as a struct containing a long
long, a long double, and optionally a __float128. It could have reduced
the size by making it a union rather than a struct, but there's rarely
(?) any reason to create objects of type max_align_t.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 9/19/2023 3:08 PM, Keith Thompson wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> [...]
>> Note by the way that sizeof (max_align_t) might not be the same
>> as _Alignof (max_align_t).
>
> Indeed. I was curious about this, so I wrote a small test program that
> shows that _Alignof (max_align_t) is 16, but sizeof (max_align_t) is 32
> on the implementation I'm using.
>
> I'm using gcc, which defines max_align_t as a struct containing a long
> long, a long double, and optionally a __float128. It could have reduced
> the size by making it a union rather than a struct, but there's rarely
> (?) any reason to create objects of type max_align_t.
>

Check out this old code of mine:

https://pastebin.com/raw/f37a23918

On 2023-09-19, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> [...]
>> Note by the way that sizeof (max_align_t) might not be the same
>> as _Alignof (max_align_t).
>
> Indeed. I was curious about this, so I wrote a small test program that
> shows that _Alignof (max_align_t) is 16, but sizeof (max_align_t) is 32
> on the implementation I'm using.
>
> I'm using gcc, which defines max_align_t as a struct containing a long
> long, a long double, and optionally a __float128. It could have reduced
> the size by making it a union rather than a struct, but there's rarely
> (?) any reason to create objects of type max_align_t.

Yes there is!

union {
foo_t x;
bar_t y;

// please give my own union maximum alignment --- without undue bloat

max_align_t align;
}

A max_align_t that can only be used as _Alignof(max_align_t) is useless;
it might as well be a #define ALIGN_MAX 16 constant in some header
like <limits.h>.

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

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> [...]
>
>> Note by the way that sizeof (max_align_t) might not be the same
>> as _Alignof (max_align_t).
>
> Indeed. I was curious about this, so I wrote a small test program that
> shows that _Alignof (max_align_t) is 16, but sizeof (max_align_t) is 32
> on the implementation I'm using.

That's just what I did. :)

> I'm using gcc, which defines max_align_t as a struct containing a long
> long, a long double, and optionally a __float128. It could have reduced
> the size by making it a union rather than a struct, but there's rarely
> (?) any reason to create objects of type max_align_t.

AFAICT there is never any reason to use max_align_t as the
type in any declaration, excepting perhaps for probing the
environment like the little test programs mentioned.

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

> On 2023-09-19, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [...]
>>
>>> Note by the way that sizeof (max_align_t) might not be the same
>>> as _Alignof (max_align_t).
>>
>> Indeed. I was curious about this, so I wrote a small test program that
>> shows that _Alignof (max_align_t) is 16, but sizeof (max_align_t) is 32
>> on the implementation I'm using.
>>
>> I'm using gcc, which defines max_align_t as a struct containing a long
>> long, a long double, and optionally a __float128. It could have reduced
>> the size by making it a union rather than a struct, but there's rarely
>> (?) any reason to create objects of type max_align_t.
>
> Yes there is!
>
> union {
> foo_t x;
> bar_t y;
>
> // please give my own union maximum alignment --- without undue bloat
>
> max_align_t align;
> }
>
> A max_align_t that can only be used as _Alignof(max_align_t) is useless;
> it might as well be a #define ALIGN_MAX 16 constant in some header
> like <limits.h>.

You need to think harder.

One: it's easy to get the alignment result you want
without using max_align_t as the type of a member (or
any other object).

Two: there are advantages to having max_align_t be a
type, so it can be used with _Alignas, that are
harder to accomplish if the value is just a #define.

Three: it can be more convenient for an implementation
to provide the max_align_t type as a type than it is
to have to construct the value in the preprocessor
(where sizeof and _Alignof don't work). Witness how
this information is provided in the gcc library
header - much easier than having to figure out the
value 16 and put it in a #define.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>> On 2023-09-19, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> [...]
>>>
>>>> Note by the way that sizeof (max_align_t) might not be the same
>>>> as _Alignof (max_align_t).
>>>
>>> Indeed. I was curious about this, so I wrote a small test program that
>>> shows that _Alignof (max_align_t) is 16, but sizeof (max_align_t) is 32
>>> on the implementation I'm using.
>>>
>>> I'm using gcc, which defines max_align_t as a struct containing a long
>>> long, a long double, and optionally a __float128. It could have reduced
>>> the size by making it a union rather than a struct, but there's rarely
>>> (?) any reason to create objects of type max_align_t.
>>
>> Yes there is!
>>
>> union {
>> foo_t x;
>> bar_t y;
>>
>> // please give my own union maximum alignment --- without undue bloat
>>
>> max_align_t align;
>> }
>>
>> A max_align_t that can only be used as _Alignof(max_align_t) is useless;
>> it might as well be a #define ALIGN_MAX 16 constant in some header
>> like <limits.h>.
>
> You need to think harder.
>
> One: it's easy to get the alignment result you want
> without using max_align_t as the type of a member (or
> any other object).

How? I don't think _Alignas can be used for this.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>> On 2023-09-19, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> [...]
>>>>
>>>>> Note by the way that sizeof (max_align_t) might not be the same
>>>>> as _Alignof (max_align_t).
>>>>
>>>> Indeed. I was curious about this, so I wrote a small test
>>>> program that shows that _Alignof (max_align_t) is 16, but sizeof
>>>> (max_align_t) is 32 on the implementation I'm using.
>>>>
>>>> I'm using gcc, which defines max_align_t as a struct containing a
>>>> long long, a long double, and optionally a __float128. It could
>>>> have reduced the size by making it a union rather than a struct,
>>>> but there's rarely (?) any reason to create objects of type
>>>> max_align_t.
>>>
>>> Yes there is!
>>>
>>> union {
>>> foo_t x;
>>> bar_t y;
>>>
>>> // please give my own union maximum alignment
>>> // [but] without undue bloat
>>>
>>> max_align_t align;
>>> }
>>>
>>> A max_align_t that can only be used as _Alignof(max_align_t) is
>>> useless; it might as well be a #define ALIGN_MAX 16 constant in
>>> some header like <limits.h>.
>>
>> You need to think harder.
>>
>> One: it's easy to get the alignment result you want
>> without using max_align_t as the type of a member (or
>> any other object).
>
> How? I don't think _Alignas can be used for this.
>
> [...]

I haven't used the new alignment features really at all
until just recently, but it took only a few minutes to
find this:

#include <stddef.h>

union au {
int x;
short y;
_Alignas (max_align_t) char stuff[ 1 ];
};

It isn't necessary to make the 'stuff' member be an array,
that was just the first thought I had (well, that worked).
My test program shows this type has a size of 16 and an
alignment of 16.

Incidentally, the only resource I consulted to understand
how the new alignment features work is the C11 (draft)
standard.

On 2023-09-20, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>> On 2023-09-19, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> [...]
>>>
>>>> Note by the way that sizeof (max_align_t) might not be the same
>>>> as _Alignof (max_align_t).
>>>
>>> Indeed. I was curious about this, so I wrote a small test program that
>>> shows that _Alignof (max_align_t) is 16, but sizeof (max_align_t) is 32
>>> on the implementation I'm using.
>>>
>>> I'm using gcc, which defines max_align_t as a struct containing a long
>>> long, a long double, and optionally a __float128. It could have reduced
>>> the size by making it a union rather than a struct, but there's rarely
>>> (?) any reason to create objects of type max_align_t.
>>
>> Yes there is!
>>
>> union {
>> foo_t x;
>> bar_t y;
>>
>> // please give my own union maximum alignment --- without undue bloat
>>
>> max_align_t align;
>> }
>>
>> A max_align_t that can only be used as _Alignof(max_align_t) is useless;
>> it might as well be a #define ALIGN_MAX 16 constant in some header
>> like <limits.h>.
>
> You need to think harder.

I'm "thinking broader" instead, maybe?

> One: it's easy to get the alignment result you want
> without using max_align_t as the type of a member (or
> any other object).

Like almost everyone here, I know how to get my union aligned in
multiple ways.

It would be better if the above solution would Just Work too.

It uses widely portable syntax, only a definition of max_align_t is
required, which can be provided somehow if unavailable.

> Two: there are advantages to having max_align_t be a
> type, so it can be used with _Alignas, that are
> harder to accomplish if the value is just a #define.

Though I didn't intend to argue for the advantages of having these kinds
of values (also) as preprocessor constants, there are advantages.

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

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)

When did C abandon its style of lower case, underscore-
separated identifiers? Why not `alignof' or at least
`_alignof'?

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

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)) ); }
printf("\n");
}

int main()
{ char* const data = malloc(5);
for( int i = 0; i < 5; i += 1 )
{ data[i] = (char)i%2; }

print_as( data );
print_as( data+1 );

return 0;
}

On my shell server, this progrma works, printing:

256 256
1 1

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Anton Shepelev wrote:

> When did C abandon its style of lower case, underscore- separated
> identifiers? Why not `alignof' or at least `_alignof'?

It's the only option that they had. The standard reserves names beginning
with two underscores and names beginning with an underscore followed by a
_capital_ letter, and they don't want to introduce names outside of those
spaces. That being said, they introduced headers for the names they
_really_ wanted to use, such as your mentioned alignof, and in C23 those
extra names have been added to the language proper and some new names have
skipped the namespaces, such as the "new" typeof keyword.

--
Blue-Maned_Hawk│shortens to Hawk│/
blu.mɛin.dÊ°ak/│he/him/his/himself/
Mr. bluemanedhawk.github.io
I've always pronounced them /ʔæ.lɪg.nɑf/ and /ʔæ.lɪg.næz/.

On 9/23/23 17:39, Anton Shepelev wrote:
....
> When did C abandon its style of lower case, underscore-
> separated identifiers? ...

In C99. It was realized that whenever a new keyword was added, it should
be taken from the space of names that were reserved to the
implementation; otherwise, it could break previously legal user code
that used that identifier for some different, perfectly legal purpose.
That's why new keywords in that version of the standard included _Bool,
_Complex, and _Imaginary. All keywords introduced since that time have
generally obeyed that convention.

> ... Why not `alignof' or at least
> `_alignof'?

Because both"alignof" and "_alignof" are from the name space reserved
for users, and therefore might be in use in existing code.

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.

> 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
% 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.

> print_as( data );
> print_as( data+1 );
>
> return 0;
> }
>
> On my shell server, this progrma works, printing:
>
> 256 256
> 1 1

"works" depends on assumptions about the system where you ran this. I can
guess what those assumptions are but it's best to state them explicitly.

--
Offsets are structures. Structures are offsets.
Charles Melice
http://al.howardknight.net/?ID=169555586400