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

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

Nice way of allocating flexible struct.

Started byKaz Kylheku <643-408-1753@kylheku.com>
First post2025-10-08 06:35 +0000
Last post2025-12-14 22:48 -0800
Articles 13 on this page of 73 — 14 participants

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

Contents

  Nice way of allocating flexible struct. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-08 06:35 +0000
    Re: Nice way of allocating flexible struct. pozz <pozzugno@gmail.com> - 2025-10-08 09:09 +0200
      Re: Nice way of allocating flexible struct. richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-10-08 12:01 +0000
      Re: Nice way of allocating flexible struct. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-08 15:23 +0000
        Re: Nice way of allocating flexible struct. Michael S <already5chosen@yahoo.com> - 2025-10-08 19:04 +0300
          Re: Nice way of allocating flexible struct. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-08 20:05 +0000
      Re: Nice way of allocating flexible struct. Michael S <already5chosen@yahoo.com> - 2025-10-08 18:52 +0300
      Re: Nice way of allocating flexible struct. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-14 23:55 -0800
    Re: Nice way of allocating flexible struct. Bonita Montero <Bonita.Montero@gmail.com> - 2025-10-08 11:09 +0200
      Re: Nice way of allocating flexible struct. Bonita Montero <Bonita.Montero@gmail.com> - 2025-10-08 11:23 +0200
        Re: Nice way of allocating flexible struct. Michael S <already5chosen@yahoo.com> - 2025-10-08 12:53 +0300
          Re: Nice way of allocating flexible struct. Bonita Montero <Bonita.Montero@gmail.com> - 2025-10-08 12:09 +0200
            Re: Nice way of allocating flexible struct. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-08 15:59 +0200
              Re: Nice way of allocating flexible struct. BGB <cr88192@gmail.com> - 2025-10-08 12:29 -0500
                Re: Nice way of allocating flexible struct. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-08 21:04 +0200
                  Re: Nice way of allocating flexible struct. BGB <cr88192@gmail.com> - 2025-10-08 22:49 -0500
                    Re: Nice way of allocating flexible struct. bart <bc@freeuk.com> - 2025-10-10 01:13 +0100
                      Re: Nice way of allocating flexible struct. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-10 01:54 +0000
                        Re: Nice way of allocating flexible struct. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-09 19:43 -0700
                        Re: Nice way of allocating flexible struct. bart <bc@freeuk.com> - 2025-10-10 11:25 +0100
                      Re: Nice way of allocating flexible struct. BGB <cr88192@gmail.com> - 2025-10-09 22:50 -0500
                      Re: Nice way of allocating flexible struct. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-09 20:59 -0700
                        Re: Nice way of allocating flexible struct. BGB <cr88192@gmail.com> - 2025-10-10 01:27 -0500
                          Re: Nice way of allocating flexible struct. David Brown <david.brown@hesbynett.no> - 2025-10-10 12:06 +0200
                            Re: Nice way of allocating flexible struct. Michael S <already5chosen@yahoo.com> - 2025-10-10 17:28 +0300
                              Re: Nice way of allocating flexible struct. David Brown <david.brown@hesbynett.no> - 2025-10-10 17:47 +0200
                                Re: Nice way of allocating flexible struct. BGB <cr88192@gmail.com> - 2025-10-10 16:32 -0500
                                  Re: Nice way of allocating flexible struct. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-11 00:02 +0000
                                    Re: Nice way of allocating flexible struct. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-13 06:20 +0200
                            Re: Nice way of allocating flexible struct. BGB <cr88192@gmail.com> - 2025-10-10 15:01 -0500
                            Re: Nice way of allocating flexible struct. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-10 23:45 +0000
                        Re: Nice way of allocating flexible struct. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-06 18:24 -0800
                    Re: Nice way of allocating flexible struct. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-14 06:29 +0200
                      Re: Nice way of allocating flexible struct. BGB <cr88192@gmail.com> - 2025-10-14 20:13 -0500
                        Re: Nice way of allocating flexible struct. bart <bc@freeuk.com> - 2025-10-15 11:26 +0100
                          Re: Nice way of allocating flexible struct. BGB <cr88192@gmail.com> - 2025-10-15 13:00 -0500
                            Re: Nice way of allocating flexible struct. bart <bc@freeuk.com> - 2025-10-17 22:07 +0100
                              Re: Nice way of allocating flexible struct. BGB <cr88192@gmail.com> - 2025-10-17 17:44 -0500
                            Re: Nice way of allocating flexible struct. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-20 10:02 +0200
                              Re: Nice way of allocating flexible struct. BGB <cr88192@gmail.com> - 2025-10-20 04:42 -0500
                                Re: Nice way of allocating flexible struct. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-21 03:40 +0200
                          Re: Nice way of allocating flexible struct. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-16 06:45 +0200
                        Re: Nice way of allocating flexible struct. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-16 06:37 +0200
                          Re: Nice way of allocating flexible struct. BGB <cr88192@gmail.com> - 2025-10-16 04:43 -0500
                            Re: Nice way of allocating flexible struct. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-20 09:58 +0200
                              Re: Nice way of allocating flexible struct. rbowman <bowman@montana.com> - 2025-10-20 18:36 +0000
                                Re: Nice way of allocating flexible struct. BGB <cr88192@gmail.com> - 2025-10-20 16:44 -0500
                                  Re: Nice way of allocating flexible struct. rbowman <bowman@montana.com> - 2025-10-21 01:33 +0000
                                  Language-design, tradeoffs (was Re: Nice way of allocating flexible struct.) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-21 04:19 +0200
                                    Re: Language-design, tradeoffs (was Re: Nice way of allocating flexible struct.) BGB <cr88192@gmail.com> - 2025-10-21 04:27 -0500
                                      Re: Language-design, tradeoffs (was Re: Nice way of allocating flexible struct.) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-22 02:30 +0200
                                        Re: Language-design, tradeoffs (was Re: Nice way of allocating flexible struct.) BGB <cr88192@gmail.com> - 2025-10-22 02:10 -0500
                                Re: Nice way of allocating flexible struct. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-21 03:51 +0200
                                  Re: Nice way of allocating flexible struct. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-20 19:21 -0700
                                    Re: Nice way of allocating flexible struct. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-21 04:53 +0200
                                    Re: Nice way of allocating flexible struct. rbowman <bowman@montana.com> - 2025-10-21 18:21 +0000
                                      Re: Nice way of allocating flexible struct. BGB <cr88192@gmail.com> - 2025-10-21 13:42 -0500
                                  Re: Nice way of allocating flexible struct. James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-10-21 06:17 -0400
                                    Re: Nice way of allocating flexible struct. rbowman <bowman@montana.com> - 2025-10-21 18:41 +0000
                                  Re: Nice way of allocating flexible struct. rbowman <bowman@montana.com> - 2025-10-21 18:12 +0000
              Re: Nice way of allocating flexible struct. Bonita Montero <Bonita.Montero@gmail.com> - 2025-10-08 19:36 +0200
                Re: Nice way of allocating flexible struct. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-08 19:51 +0200
      Re: Nice way of allocating flexible struct. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-08 15:29 +0000
    Re: Nice way of allocating flexible struct. BGB <cr88192@gmail.com> - 2025-10-08 11:33 -0500
      Re: Nice way of allocating flexible struct. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-08 14:57 -0700
        Re: Nice way of allocating flexible struct. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-09 01:39 +0000
          Re: Nice way of allocating flexible struct. BGB <cr88192@gmail.com> - 2025-10-08 22:25 -0500
            Re: Nice way of allocating flexible struct. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-09 19:50 -0700
              Re: Nice way of allocating flexible struct. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-10 04:20 +0000
        Re: Nice way of allocating flexible struct. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-15 11:24 -0800
    Re: Nice way of allocating flexible struct. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-08 13:35 -0700
      Re: Nice way of allocating flexible struct. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-08 13:36 -0700
    Re: Nice way of allocating flexible struct. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-14 22:48 -0800

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

#394508

FromBonita Montero <Bonita.Montero@gmail.com>
Date2025-10-08 19:36 +0200
Message-ID<10c67eq$1ond9$1@raubtier-asyl.eternal-september.org>
In reply to#394497
Am 08.10.2025 um 15:59 schrieb Janis Papanagnou:

> I disagree in the historic valuation; abstractions were known and
> used (and asked for) already [long] before. ...

Compared to C++ they're almost not possible in C compared to mordern
languages.

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

#394509

FromJanis Papanagnou <janis_papanagnou+ng@hotmail.com>
Date2025-10-08 19:51 +0200
Message-ID<10c68a7$1ovsg$1@dont-email.me>
In reply to#394508
On 08.10.2025 19:36, Bonita Montero wrote:
> Am 08.10.2025 um 15:59 schrieb Janis Papanagnou:
> 
>> I disagree in the historic valuation; abstractions were known and
>> used (and asked for) already [long] before. ...
> 
> Compared to C++ they're almost not possible in C compared to mordern
> languages.

No doubt. (My statement was just addressing the historic aspect of
your post.)

Janis

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

#394503

FromKaz Kylheku <643-408-1753@kylheku.com>
Date2025-10-08 15:29 +0000
Message-ID<20251008082554.513@kylheku.com>
In reply to#394490
On 2025-10-08, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 08.10.2025 um 08:35 schrieb Kaz Kylheku:
>> Jonas Lund of https://whizzter.woorlic.org/ mentioned this
>> trick in a HackerNews comment:
>> 
>> Given:
>> 
>>    struct S {
>>      // ...
>>      T A[];
>>    };
>> 
>> Don't do this:
>> 
>>    malloc(offsetof(S, A) + n * sizeof (T));
>> 
>> But rather this:
>> 
>>    malloc(offsetof(S, A[n]));
>> 
>> It's easy to forget that the second argument of offsetof is a
>> designator, not simply a member name.
>> 
>
> In a real language:

That HackerNews comment I alluded to actually arose in the context
of C++ code that was using struct hack.

The size is not know at compile time, so it cannot be a template
parameter.

It is also important that the entire object, header plus data,
is one memory allocation. It is less overhead. Also, given a
pointer to the structure, the pointer to the flexible array
data is just a displacement calculation: there is no additional
pointer to load to get to the data.

You should be glad you have the technique available in C++.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#394506

FromBGB <cr88192@gmail.com>
Date2025-10-08 11:33 -0500
Message-ID<10c63rl$1n5qf$1@dont-email.me>
In reply to#394488
On 10/8/2025 1:35 AM, Kaz Kylheku wrote:
> Jonas Lund of https://whizzter.woorlic.org/ mentioned this
> trick in a HackerNews comment:
> 
> Given:
> 
>    struct S {
>      // ...
>      T A[];
>    };
> 
> Don't do this:
> 
>    malloc(offsetof(S, A) + n * sizeof (T));
> 
> But rather this:
> 
>    malloc(offsetof(S, A[n]));
> 
> It's easy to forget that the second argument of offsetof is a
> designator, not simply a member name.
> 

This is assuming offsetof and can deal with general expressions (vs just 
field names). IIRC, it is only required to work with field names (and 
with plain structs).

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

#394514

FromKeith Thompson <Keith.S.Thompson+u@gmail.com>
Date2025-10-08 14:57 -0700
Message-ID<87347thx9h.fsf@example.invalid>
In reply to#394506
BGB <cr88192@gmail.com> writes:
> On 10/8/2025 1:35 AM, Kaz Kylheku wrote:
>> Jonas Lund of https://whizzter.woorlic.org/ mentioned this
>> trick in a HackerNews comment:
>> Given:
>>    struct S {
>>      // ...
>>      T A[];
>>    };
>> Don't do this:
>>    malloc(offsetof(S, A) + n * sizeof (T));
>> But rather this:
>>    malloc(offsetof(S, A[n]));
>> It's easy to forget that the second argument of offsetof is a
>> designator, not simply a member name.
>
> This is assuming offsetof and can deal with general expressions (vs
> just field names). IIRC, it is only required to work with field names
> (and with plain structs).

I just read that part of the standard, and it's not clear whether
the second argument to offsetof() has to be a member name or whether
it can be something more elaborate.

Quoting the N3096 draft of C23, 7.21:

    offsetof(type, member-designator)

    which expands to an integer constant expression that has type
    `size_t`, the value of which is the offset in bytes, to the
    subobject (designated by *member-designator*), from the beginning
    of any object of type *type*. The type and member designator
    shall be such that given

        static type t;

    then the expression &(t. *member-designator*) evaluates to
    an address constant. If the specified *type* defines a new
    type or if the specified member is a bit-field, the behavior
    is undefined.

The requirements imply that the type can be a struct or a union.

The term "member designator" is not used elsewhere in the standard.
If the term to be taken literally, then it has to designate a
*member*, not an element of a member.  But the term "subobject",
along with the address constant requirement, could imply that it
could be an arbitrary sequence of members and array elements.

But in addition to that, in Kaz's example, n is not a constant
expression, so `&(t.member-designator)` is not an address constant
and therefore `offsetof(S, A[n])` has undefined behavior.

Every compiler I've tried handles this "correctly", and I tend to
think that a compiler would have to go out of its way not to do so.
I'd like to see a future standard make offsetof more flexible,
with defined behavior for cases like this.

The C99 Rationale shows these possible definitions:

    (size_t)&(((s_name*)0)->m_name)

    (size_t)(char*)&(((s_name*)0)->m_name)

which, if they work, should handle Kaz's example correctly.

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

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

#394515

FromKaz Kylheku <643-408-1753@kylheku.com>
Date2025-10-09 01:39 +0000
Message-ID<20251008183724.803@kylheku.com>
In reply to#394514
On 2025-10-08, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> But in addition to that, in Kaz's example, n is not a constant
> expression, so `&(t.member-designator)` is not an address constant
> and therefore `offsetof(S, A[n])` has undefined behavior.

Great; I'd like to hear reasons to avoid it so I don't look foolish
for having overlooked it for manytyears. :)

> Every compiler I've tried handles this "correctly", and I tend to

I'm sure I've seen foo.bar expressions on the right of an offsetof,
but those still yield constants.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#394516

FromBGB <cr88192@gmail.com>
Date2025-10-08 22:25 -0500
Message-ID<10c7a0v$24vls$1@dont-email.me>
In reply to#394515
On 10/8/2025 8:39 PM, Kaz Kylheku wrote:
> On 2025-10-08, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> But in addition to that, in Kaz's example, n is not a constant
>> expression, so `&(t.member-designator)` is not an address constant
>> and therefore `offsetof(S, A[n])` has undefined behavior.
> 
> Great; I'd like to hear reasons to avoid it so I don't look foolish
> for having overlooked it for manytyears. :)
> 
>> Every compiler I've tried handles this "correctly", and I tend to
> 
> I'm sure I've seen foo.bar expressions on the right of an offsetof,
> but those still yield constants.
> 

I think it is a case of, it is not required to work...

But, if the typical implementation is something like, say:
#define offsetof(T, M)  ((long)(&(((T *)0)->M)))

It is probably going to work without issue.

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

#394522

FromKeith Thompson <Keith.S.Thompson+u@gmail.com>
Date2025-10-09 19:50 -0700
Message-ID<87y0pjh3lo.fsf@example.invalid>
In reply to#394516
BGB <cr88192@gmail.com> writes:
> On 10/8/2025 8:39 PM, Kaz Kylheku wrote:
>> On 2025-10-08, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> But in addition to that, in Kaz's example, n is not a constant
>>> expression, so `&(t.member-designator)` is not an address constant
>>> and therefore `offsetof(S, A[n])` has undefined behavior.
>> Great; I'd like to hear reasons to avoid it so I don't look foolish
>> for having overlooked it for manytyears. :)
>> 
>>> Every compiler I've tried handles this "correctly", and I tend to
>> I'm sure I've seen foo.bar expressions on the right of an offsetof,
>> but those still yield constants.
>> 
>
> I think it is a case of, it is not required to work...
>
> But, if the typical implementation is something like, say:
> #define offsetof(T, M)  ((long)(&(((T *)0)->M)))
>
> It is probably going to work without issue.

The cast needs to be (size_t), not (long).  With that change,
the behavior is still undefined, but it's likely to work in most
implementations, which is all that's required for code that's part
of the implementation.

Several implementations I've tried (gcc, clang, tcc) implement the
offsetof macro via "__builtin_offsetof".  Whatever compiler magic
is used to implement "__builtin_offsetof" typically works correctly
for Kaz's example (which is of course one of the possible results of
undefined behavior).  One other compiler I've tried has a #define
similar to yours (and also gets the type wrong, but the author of
that implementation is not interested in bug reports from me).

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

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

#394525

FromKaz Kylheku <643-408-1753@kylheku.com>
Date2025-10-10 04:20 +0000
Message-ID<20251009210948.632@kylheku.com>
In reply to#394522
On 2025-10-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Several implementations I've tried (gcc, clang, tcc) implement the
> offsetof macro via "__builtin_offsetof".  Whatever compiler magic
> is used to implement "__builtin_offsetof" typically works correctly
> for Kaz's example (which is of course one of the possible results of
> undefined behavior).

It is a documented extension, because GCC parses it, and the reason is
given in GCC's documented grammar for the feature:

primary:
        "__builtin_offsetof" "(" typename "," offsetof_member_designator ")"

offsetof_member_designator:
          identifier
        | offsetof_member_designator "." identifier
        | offsetof_member_designator "[" expr "]"

Accompanied by the remark: "In either case, member may consist of a
single identifier, or a sequence of member accesses and array
references."

This is a section under: https://gcc.gnu.org/onlinedocs/gcc/Syntax-Extensions.html

Expr is not constrained to be constant.

It is not explained what the semantics is of the extended designator,
but it can be reasonably inferred.

There are probably code bases out there which perpetrate that trick;
GCC has been in many places and had lots of people hack on it.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#395823

FromTim Rentsch <tr.17687@z991.linuxsc.com>
Date2025-12-15 11:24 -0800
Message-ID<86cy4ftuoi.fsf@linuxsc.com>
In reply to#394514
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> BGB <cr88192@gmail.com> writes:
>
>> On 10/8/2025 1:35 AM, Kaz Kylheku wrote:
>>
>>> Jonas Lund of https://whizzter.woorlic.org/ mentioned this
>>> trick in a HackerNews comment:
>>> Given:
>>>    struct S {
>>>      // ...
>>>      T A[];
>>>    };
>>> Don't do this:
>>>    malloc(offsetof(S, A) + n * sizeof (T));
>>> But rather this:
>>>    malloc(offsetof(S, A[n]));
>>> It's easy to forget that the second argument of offsetof is a
>>> designator, not simply a member name.
>>
>> This is assuming offsetof and can deal with general expressions (vs
>> just field names).  IIRC, it is only required to work with field names
>> (and with plain structs).
>
> I just read that part of the standard, and it's not clear whether
> the second argument to offsetof() has to be a member name or whether
> it can be something more elaborate.
>
> Quoting the N3096 draft of C23, 7.21:
>
>     offsetof(type, member-designator)
>
>     which expands to an integer constant expression that has type
>     `size_t`, the value of which is the offset in bytes, to the
>     subobject (designated by *member-designator*), from the beginning
>     of any object of type *type*. The type and member designator
>     shall be such that given
>
>         static type t;
>
>     then the expression &(t.  *member-designator*) evaluates to
>     an address constant.  If the specified *type* defines a new
>     type or if the specified member is a bit-field, the behavior
>     is undefined.
>
> The requirements imply that the type can be a struct or a union.
>
> The term "member designator" is not used elsewhere in the standard.
> If the term to be taken literally, then it has to designate a
> *member*, not an element of a member.  But the term "subobject",
> along with the address constant requirement, could imply that it
> could be an arbitrary sequence of members and array elements.

Clearly the italicized token member-designator is just a placeholder
with no semantics implied, and the controlling text here is the word
"subobject", which applies recursively.

Note also that the phrase "from the beginning of any object of type
*type*" precludes the use of 'offsetof(S, A[n])', if n is too large,
since A[n] will not be a subobject of an arbitrary object of type
*type*.

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

#394512

From"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date2025-10-08 13:35 -0700
Message-ID<10c6htq$1r7pq$3@dont-email.me>
In reply to#394488
On 10/7/2025 11:35 PM, Kaz Kylheku wrote:
> Jonas Lund of https://whizzter.woorlic.org/ mentioned this
> trick in a HackerNews comment:
> 
> Given:
> 
>    struct S {
>      // ...
>      T A[];
>    };
> 
> Don't do this:
> 
>    malloc(offsetof(S, A) + n * sizeof (T));
> 
> But rather this:
> 
>    malloc(offsetof(S, A[n]));
> 
> It's easy to forget that the second argument of offsetof is a
> designator, not simply a member name.
> 

For some god damn reason its raising memories of an older region 
allocator I mocked up in C:

Still on pastebin. funny:

https://groups.google.com/g/comp.lang.c/c/H_p2Ki5JhYU/m/rlSzqJsxCQAJ

https://pastebin.com/raw/f37a23918
(no ads, raw text)

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

#394513

From"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date2025-10-08 13:36 -0700
Message-ID<10c6hvu$1r9j2$2@dont-email.me>
In reply to#394512
On 10/8/2025 1:35 PM, Chris M. Thomasson wrote:
> On 10/7/2025 11:35 PM, Kaz Kylheku wrote:
>> Jonas Lund of https://whizzter.woorlic.org/ mentioned this
>> trick in a HackerNews comment:
>>
>> Given:
>>
>>    struct S {
>>      // ...
>>      T A[];
>>    };
>>
>> Don't do this:
>>
>>    malloc(offsetof(S, A) + n * sizeof (T));
>>
>> But rather this:
>>
>>    malloc(offsetof(S, A[n]));
>>
>> It's easy to forget that the second argument of offsetof is a
>> designator, not simply a member name.
>>
> 
> For some god damn reason its raising memories of an older region 
> allocator I mocked up in C:
> 
> Still on pastebin. funny:
> 
> https://groups.google.com/g/comp.lang.c/c/H_p2Ki5JhYU/m/rlSzqJsxCQAJ
> 
> https://pastebin.com/raw/f37a23918
> (no ads, raw text)

Strange. For mock up alignment:

#define RALLOC_ALIGN_OF(mp_type) \
   offsetof( \
     struct { \
       char pad_RALLOC_ALIGN_OF; \
       mp_type type_RALLOC_ALIGN_OF; \
     }, \
     type_RALLOC_ALIGN_OF \
   )

;^)

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

#395810

FromTim Rentsch <tr.17687@z991.linuxsc.com>
Date2025-12-14 22:48 -0800
Message-ID<86jyyouto5.fsf@linuxsc.com>
In reply to#394488
Kaz Kylheku <643-408-1753@kylheku.com> writes:

> Jonas Lund of https://whizzter.woorlic.org/ mentioned this
> trick in a HackerNews comment:
>
> Given:
>
>   struct S {
>     // ...
>     T A[];
>   };
>
> Don't do this:
>
>   malloc(offsetof(S, A) + n * sizeof (T));
>
> But rather this:
>
>   malloc(offsetof(S, A[n]));
>
> It's easy to forget that the second argument of offsetof is a
> designator, not simply a member name.

Clever but inadvisable.  Even if the offsetof() expression compiles,
in most cases it either gives a value that is too small or is
undefined behavior.

[toc] | [prev] | [standalone]

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

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

csiph-web