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

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

Offsetof with array elements

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

Contents

  Offsetof with array elements David Brown <david.brown@hesbynett.no> - 2020-02-11 15:31 +0100
    Re: Offsetof with array elements Guillaume <message@bottle.org> - 2020-02-11 16:08 +0100
      Re: Offsetof with array elements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-11 08:32 -0800
        Re: Offsetof with array elements David Brown <david.brown@hesbynett.no> - 2020-02-11 18:46 +0100
          Re: Offsetof with array elements Manfred <noname@add.invalid> - 2020-02-11 19:24 +0100
            Re: Offsetof with array elements Manfred <noname@add.invalid> - 2020-02-11 19:36 +0100
            Re: Offsetof with array elements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-11 22:50 -0500
              Re: Offsetof with array elements Manfred <noname@add.invalid> - 2020-02-12 13:53 +0100
              Re: Offsetof with array elements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-18 01:43 -0800
      Re: Offsetof with array elements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-18 01:39 -0800
    Re: Offsetof with array elements Bart <bc@freeuk.com> - 2020-02-11 16:56 +0000
      Re: Offsetof with array elements David Brown <david.brown@hesbynett.no> - 2020-02-11 18:49 +0100
    Re: Offsetof with array elements Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-11 21:00 +0100
      Re: Offsetof with array elements Bart <bc@freeuk.com> - 2020-02-11 20:13 +0000
        Re: Offsetof with array elements Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-11 21:24 +0100
          Re: Offsetof with array elements Bart <bc@freeuk.com> - 2020-02-11 20:33 +0000
            Re: Offsetof with array elements Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-11 21:39 +0100
              Re: Offsetof with array elements Bart <bc@freeuk.com> - 2020-02-11 20:48 +0000
      Re: Offsetof with array elements David Brown <david.brown@hesbynett.no> - 2020-02-12 10:56 +0100
        Re: Offsetof with array elements Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-12 14:07 +0100
          Re: Offsetof with array elements David Brown <david.brown@hesbynett.no> - 2020-02-12 15:24 +0100
      Re: Offsetof with array elements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-12 10:39 +0000
        Re: Offsetof with array elements Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-12 14:08 +0100
          Re: Offsetof with array elements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-12 05:29 -0800
            Re: Offsetof with array elements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-12 11:45 -0800
          Re: Offsetof with array elements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-12 17:50 +0000
        Re: Offsetof with array elements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 02:41 -0800
          Re: Offsetof with array elements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-16 11:18 +0000
      Re: Offsetof with array elements already5chosen@yahoo.com - 2020-02-13 02:42 -0800
        Re: Offsetof with array elements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-14 00:20 -0500
          Re: Offsetof with array elements David Brown <david.brown@hesbynett.no> - 2020-02-14 08:24 +0100
            Re: Offsetof with array elements already5chosen@yahoo.com - 2020-02-14 03:59 -0800
              Re: Offsetof with array elements David Brown <david.brown@hesbynett.no> - 2020-02-14 15:25 +0100
                Re: Offsetof with array elements already5chosen@yahoo.com - 2020-02-16 03:15 -0800
                  Re: Offsetof with array elements David Brown <david.brown@hesbynett.no> - 2020-02-16 14:09 +0100
                    Re: Offsetof with array elements already5chosen@yahoo.com - 2020-02-16 06:36 -0800
            Re: Offsetof with array elements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-15 08:18 -0500
              Re: Offsetof with array elements David Brown <david.brown@hesbynett.no> - 2020-02-15 15:49 +0100
    Re: Offsetof with array elements fir <profesor.fir@gmail.com> - 2020-02-12 04:40 -0800
    Re: Offsetof with array elements "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-02-16 16:03 -0800

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

#149975

On 12/02/2020 14:07, Bonita Montero wrote:
>> I have no problem finding the offset to the array item. ...
> 
> So your question is a waste of time.
> 

No - otherwise I would not have asked it.

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

#149965

Bonita Montero <Bonita.Montero@gmail.com> writes:

> How about this:
>
> #include <stddef.h>
> #define array_offsetof(type, member, index) (size_t)(offsetof(type, member) + sizeof(((type *)NULL)->##member[0]) * index)

The ## is wrong.  Maybe it was typo?  There are no valid tokens that
start -> (other than -> itself) so pasting any other token to -> will
always be an error.

It has undefined behaviour (dereferencing a null pointer) but may well
work.  However, if you are prepared to accept that portability risk, why
not use the simpler, two argument, macro that has already been posted?

-- 
Ben.

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

#149971

> The ## is wrong. ...

Maybe useless, but not necessarily wrong.
Compiled as C++ with MSVC++ everything is o.k..

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

#149973

On Wednesday, February 12, 2020 at 8:08:54 AM UTC-5, Bonita Montero wrote:
> > The ## is wrong. ...
> 
> Maybe useless, but not necessarily wrong.

Yes, it's a syntax error.

> Compiled as C++ with MSVC++ everything is o.k..

Every compiler accepts some code that is wrong, MSVC++ more than most.

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

#149980

I said that wrong. In the macro you suggested,

#define array_offsetof(type, member, index) (size_t)(offsetof(type,
member) + sizeof(((type *)NULL)->##member[0]) * index)

your use of ## is not, in itself, a syntax error.
However, it is guaranteed to result in a syntax
error. Think for a moment about what ->##member
is supposed to do. It is supposed to first
replace "member" with the reprocessing tokens
Of the corresponding macro argument. Then it's
supposed to take the reprocessing token that
immediately precedes the ## (which is "->" in
this case), and the one that immediately
follows it (which, in this case, will normally
be the identifier for a member of the struct),
and concatenate them together to form a single
preprocessing token.
Now, why would you tell it to do that? The
character sequence "->member_identifier"
doesn't match any of the permitted forms for a
single preprocessing token. There's nothing
that you could pass as the second argument that
would result in a valid preprocessing token
after that concatenation. That sequence of
characters would normally be parsed as two
separate tokens, "->" and "member_identifier",
which would work fine. However, such parsing is
already complete by the time ## operators are
evaluated. What ## puts together will never
again be taken apart. If it doesn't already have
the correct form to qualify as a single
preprocessing token, the behavior is simply
undefined.
I suspect you had a subtly different concept of
what ## does, a concept that makes it not merely
harmless in this context, but actually necessary
for some reason. There is no such reason - with
the ## removed, that macro would do precisely
what I believe you wanted it to do.

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

#149979

Bonita Montero <Bonita.Montero@gmail.com> writes:

>> The ## is wrong. ...
>
> Maybe useless, but not necessarily wrong.
> Compiled as C++ with MSVC++ everything is o.k..

This is comp.lang.c but C++ happens to agree here -- in both C and C++
any use of your macro produced undefined behaviour.  That can include
accepting the code by not doing what ## usually means.  That's somewhat
worse than "useless".

-- 
Ben.

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

#150041

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> How about this:
>>
>> #include <stddef.h>
>> #define array_offsetof(type, member, index) (size_t)(offsetof(type,
>> member) + sizeof(((type *)NULL)->##member[0]) * index)
>
> The ## is wrong.  Maybe it was typo?  There are no valid tokens that
> start -> (other than -> itself) so pasting any other token to -> will
> always be an error.
>
> It has undefined behaviour (dereferencing a null pointer) but may well
> work.  [...]

Why do you say the pointer dereference has undefined behavior?
The -> operator is part of an operand to 'sizeof', and hence is
not evaluated.

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

#150044

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>
>>> How about this:
>>>
>>> #include <stddef.h>
>>> #define array_offsetof(type, member, index) (size_t)(offsetof(type,
>>> member) + sizeof(((type *)NULL)->##member[0]) * index)
>>
>> The ## is wrong.  Maybe it was typo?  There are no valid tokens that
>> start -> (other than -> itself) so pasting any other token to -> will
>> always be an error.
>>
>> It has undefined behaviour (dereferencing a null pointer) but may well
>> work.  [...]
>
> Why do you say the pointer dereference has undefined behavior?

Because I was not paying attention.

> The -> operator is part of an operand to 'sizeof', and hence is
> not evaluated.

-- 
Ben.

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

#150003

On Tuesday, February 11, 2020 at 10:00:41 PM UTC+2, Bonita Montero wrote:
> How about this:
> 
> #include <stddef.h>
> #define array_offsetof(type, member, index) (size_t)(offsetof(type, 
> member) + sizeof(((type *)NULL)->##member[0]) * index)

#define array_offsetof(type, member, index) \
  (offsetof(type, member[0]) + \
  (offsetof(type, member[1]) - offsetof(type, member[0]))*(index))

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

#150017

On 2/13/20 5:42 AM, already5chosen@yahoo.com wrote:
> On Tuesday, February 11, 2020 at 10:00:41 PM UTC+2, Bonita Montero wrote:
>> How about this:
>>
>> #include <stddef.h>
>> #define array_offsetof(type, member, index) (size_t)(offsetof(type, 
>> member) + sizeof(((type *)NULL)->##member[0]) * index)
> 
> #define array_offsetof(type, member, index) \
>   (offsetof(type, member[0]) + \
>   (offsetof(type, member[1]) - offsetof(type, member[0]))*(index))

On a system where offsetof(type, member[1]) works as needed for that
expression to be valid, there is no need for array_offsetof().

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

#150018

On 14/02/2020 06:20, James Kuyper wrote:
> On 2/13/20 5:42 AM, already5chosen@yahoo.com wrote:
>> On Tuesday, February 11, 2020 at 10:00:41 PM UTC+2, Bonita Montero wrote:
>>> How about this:
>>>
>>> #include <stddef.h>
>>> #define array_offsetof(type, member, index) (size_t)(offsetof(type,
>>> member) + sizeof(((type *)NULL)->##member[0]) * index)
>>
>> #define array_offsetof(type, member, index) \
>>    (offsetof(type, member[0]) + \
>>    (offsetof(type, member[1]) - offsetof(type, member[0]))*(index))
> 
> On a system where offsetof(type, member[1]) works as needed for that
> expression to be valid, there is no need for array_offsetof().
> 

I think "offsetof(type, member[1])" should always work, since the index 
is a constant.  It is "offsetof(type, member[i])" with variable "i" that 
is not defined in the standard, and not always supported.  (But it seems 
that most compilers /do/ support it - I just happen to have come across 
an unusual one that rejects it.)

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

#150019

On Friday, February 14, 2020 at 9:24:41 AM UTC+2, David Brown wrote:
> On 14/02/2020 06:20, James Kuyper wrote:
> > On 2/13/20 5:42 AM, already5chosen@yahoo.com wrote:
> >> On Tuesday, February 11, 2020 at 10:00:41 PM UTC+2, Bonita Montero wrote:
> >>> How about this:
> >>>
> >>> #include <stddef.h>
> >>> #define array_offsetof(type, member, index) (size_t)(offsetof(type,
> >>> member) + sizeof(((type *)NULL)->##member[0]) * index)
> >>
> >> #define array_offsetof(type, member, index) \
> >>    (offsetof(type, member[0]) + \
> >>    (offsetof(type, member[1]) - offsetof(type, member[0]))*(index))
> > 
> > On a system where offsetof(type, member[1]) works as needed for that
> > expression to be valid, there is no need for array_offsetof().
> > 
> 
> I think "offsetof(type, member[1])" should always work, since the index 
> is a constant.  It is "offsetof(type, member[i])" with variable "i" that 
> is not defined in the standard, and not always supported.  (But it seems 
> that most compilers /do/ support it - I just happen to have come across 
> an unusual one that rejects it.)

TI or Microchip ?

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

#150024

On 14/02/2020 12:59, already5chosen@yahoo.com wrote:
> On Friday, February 14, 2020 at 9:24:41 AM UTC+2, David Brown wrote:
>> On 14/02/2020 06:20, James Kuyper wrote:
>>> On 2/13/20 5:42 AM, already5chosen@yahoo.com wrote:
>>>> On Tuesday, February 11, 2020 at 10:00:41 PM UTC+2, Bonita Montero wrote:
>>>>> How about this:
>>>>>
>>>>> #include <stddef.h>
>>>>> #define array_offsetof(type, member, index) (size_t)(offsetof(type,
>>>>> member) + sizeof(((type *)NULL)->##member[0]) * index)
>>>>
>>>> #define array_offsetof(type, member, index) \
>>>>    (offsetof(type, member[0]) + \
>>>>    (offsetof(type, member[1]) - offsetof(type, member[0]))*(index))
>>>
>>> On a system where offsetof(type, member[1]) works as needed for that
>>> expression to be valid, there is no need for array_offsetof().
>>>
>>
>> I think "offsetof(type, member[1])" should always work, since the index 
>> is a constant.  It is "offsetof(type, member[i])" with variable "i" that 
>> is not defined in the standard, and not always supported.  (But it seems 
>> that most compilers /do/ support it - I just happen to have come across 
>> an unusual one that rejects it.)
> 
> TI or Microchip ?
> 

TI Code Composter.  Given past experience (with joys such as "We know
that the C language says uninitialised file-scope variables will be
initialised to 0 before main() starts, but we thought it would be more
fun not to do this and just mention it as a footnote hidden in the
middle of the manual that no one reads"), when CC does something
different from other compilers, I assume CC is wrong.  In this case,
however, it seems CC is justified - but less helpful than all other
compilers I tried.

With Microchip's own compilers (as distinct from their gcc builds for
MIPS microcontrollers), you assume that the authors have never even
looked at the C standards and merely guessed at some of the language
features people might want in a C compiler.  I wouldn't have bothered
posting if it were their tools - I'd have been happy enough to see that
it supported a struct with an array member.  (Yes, Microchip used to
make - and sell, at high prices - "C" compilers that supported structs
and arrays, but not arrays of structs or structs with array members.)

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

#150043

On Friday, February 14, 2020 at 4:25:36 PM UTC+2, David Brown wrote:
> On 14/02/2020 12:59, already5chosen@yahoo.com wrote:
> > On Friday, February 14, 2020 at 9:24:41 AM UTC+2, David Brown wrote:
> >> On 14/02/2020 06:20, James Kuyper wrote:
> >>> On 2/13/20 5:42 AM, already5chosen@yahoo.com wrote:
> >>>> On Tuesday, February 11, 2020 at 10:00:41 PM UTC+2, Bonita Montero wrote:
> >>>>> How about this:
> >>>>>
> >>>>> #include <stddef.h>
> >>>>> #define array_offsetof(type, member, index) (size_t)(offsetof(type,
> >>>>> member) + sizeof(((type *)NULL)->##member[0]) * index)
> >>>>
> >>>> #define array_offsetof(type, member, index) \
> >>>>    (offsetof(type, member[0]) + \
> >>>>    (offsetof(type, member[1]) - offsetof(type, member[0]))*(index))
> >>>
> >>> On a system where offsetof(type, member[1]) works as needed for that
> >>> expression to be valid, there is no need for array_offsetof().
> >>>
> >>
> >> I think "offsetof(type, member[1])" should always work, since the index 
> >> is a constant.  It is "offsetof(type, member[i])" with variable "i" that 
> >> is not defined in the standard, and not always supported.  (But it seems 
> >> that most compilers /do/ support it - I just happen to have come across 
> >> an unusual one that rejects it.)
> > 
> > TI or Microchip ?
> > 
> 
> TI Code Composter.  Given past experience (with joys such as "We know
> that the C language says uninitialised file-scope variables will be
> initialised to 0 before main() starts, but we thought it would be more
> fun not to do this and just mention it as a footnote hidden in the
> middle of the manual that no one reads"), 

Well, I am aware of this "feature" of TI tools since time (18 or 20 years ago) when it was properly documented. So, they can't surprise me!

They did manage to surprise me last year when I found out that division of "unsigned long long" argument (40 bits) produces correct results only when the results of division fits in 32 bits. Cool, isn't it?

> when CC does something
> different from other compilers, I assume CC is wrong.  In this case,
> however, it seems CC is justified - but less helpful than all other
> compilers I tried.
> 

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

#150045

On 16/02/2020 12:15, already5chosen@yahoo.com wrote:
> On Friday, February 14, 2020 at 4:25:36 PM UTC+2, David Brown wrote:
>> On 14/02/2020 12:59, already5chosen@yahoo.com wrote:
>>> On Friday, February 14, 2020 at 9:24:41 AM UTC+2, David Brown
>>> wrote:
>>>> On 14/02/2020 06:20, James Kuyper wrote:
>>>>> On 2/13/20 5:42 AM, already5chosen@yahoo.com wrote:
>>>>>> On Tuesday, February 11, 2020 at 10:00:41 PM UTC+2, Bonita
>>>>>> Montero wrote:
>>>>>>> How about this:
>>>>>>> 
>>>>>>> #include <stddef.h> #define array_offsetof(type, member,
>>>>>>> index) (size_t)(offsetof(type, member) + sizeof(((type
>>>>>>> *)NULL)->##member[0]) * index)
>>>>>> 
>>>>>> #define array_offsetof(type, member, index) \ 
>>>>>> (offsetof(type, member[0]) + \ (offsetof(type, member[1]) -
>>>>>> offsetof(type, member[0]))*(index))
>>>>> 
>>>>> On a system where offsetof(type, member[1]) works as needed
>>>>> for that expression to be valid, there is no need for
>>>>> array_offsetof().
>>>>> 
>>>> 
>>>> I think "offsetof(type, member[1])" should always work, since
>>>> the index is a constant.  It is "offsetof(type, member[i])"
>>>> with variable "i" that is not defined in the standard, and not
>>>> always supported.  (But it seems that most compilers /do/
>>>> support it - I just happen to have come across an unusual one
>>>> that rejects it.)
>>> 
>>> TI or Microchip ?
>>> 
>> 
>> TI Code Composter.  Given past experience (with joys such as "We
>> know that the C language says uninitialised file-scope variables
>> will be initialised to 0 before main() starts, but we thought it
>> would be more fun not to do this and just mention it as a footnote
>> hidden in the middle of the manual that no one reads"),
> 
> Well, I am aware of this "feature" of TI tools since time (18 or 20
> years ago) when it was properly documented. So, they can't surprise
> me!

It certainly surprised me the first time I saw it (no doubt 20+ years
ago).  It was fun trying to figure out why behaviour was different from
power-on reset, or restarting with debugger after first running the program.

And it surprised me many years later when I used a different TI compiler
on a different platform, and they /still/ had this idiotic misfeature.
It surprised me that they hadn't learned.

> 
> They did manage to surprise me last year when I found out that
> division of "unsigned long long" argument (40 bits) produces correct
> results only when the results of division fits in 32 bits. Cool,
> isn't it?

Which target was that with a 40-bit long long?  I know they support
20-bit types on some msp430 cores (to match the 20-bit addressing).  Was
this an accumulator type for a DSP or something?

> 
>> when CC does something different from other compilers, I assume CC
>> is wrong.  In this case, however, it seems CC is justified - but
>> less helpful than all other compilers I tried.
>> 

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

#150052

On Sunday, February 16, 2020 at 3:09:31 PM UTC+2, David Brown wrote:
> On 16/02/2020 12:15, already5chosen@yahoo.com wrote:
> > On Friday, February 14, 2020 at 4:25:36 PM UTC+2, David Brown wrote:
> >> On 14/02/2020 12:59, already5chosen@yahoo.com wrote:
> >>> On Friday, February 14, 2020 at 9:24:41 AM UTC+2, David Brown
> >>> wrote:
> >>>> On 14/02/2020 06:20, James Kuyper wrote:
> >>>>> On 2/13/20 5:42 AM, already5chosen@yahoo.com wrote:
> >>>>>> On Tuesday, February 11, 2020 at 10:00:41 PM UTC+2, Bonita
> >>>>>> Montero wrote:
> >>>>>>> How about this:
> >>>>>>> 
> >>>>>>> #include <stddef.h> #define array_offsetof(type, member,
> >>>>>>> index) (size_t)(offsetof(type, member) + sizeof(((type
> >>>>>>> *)NULL)->##member[0]) * index)
> >>>>>> 
> >>>>>> #define array_offsetof(type, member, index) \ 
> >>>>>> (offsetof(type, member[0]) + \ (offsetof(type, member[1]) -
> >>>>>> offsetof(type, member[0]))*(index))
> >>>>> 
> >>>>> On a system where offsetof(type, member[1]) works as needed
> >>>>> for that expression to be valid, there is no need for
> >>>>> array_offsetof().
> >>>>> 
> >>>> 
> >>>> I think "offsetof(type, member[1])" should always work, since
> >>>> the index is a constant.  It is "offsetof(type, member[i])"
> >>>> with variable "i" that is not defined in the standard, and not
> >>>> always supported.  (But it seems that most compilers /do/
> >>>> support it - I just happen to have come across an unusual one
> >>>> that rejects it.)
> >>> 
> >>> TI or Microchip ?
> >>> 
> >> 
> >> TI Code Composter.  Given past experience (with joys such as "We
> >> know that the C language says uninitialised file-scope variables
> >> will be initialised to 0 before main() starts, but we thought it
> >> would be more fun not to do this and just mention it as a footnote
> >> hidden in the middle of the manual that no one reads"),
> > 
> > Well, I am aware of this "feature" of TI tools since time (18 or 20
> > years ago) when it was properly documented. So, they can't surprise
> > me!
> 
> It certainly surprised me the first time I saw it (no doubt 20+ years
> ago).  It was fun trying to figure out why behaviour was different from
> power-on reset, or restarting with debugger after first running the program.
> 
> And it surprised me many years later when I used a different TI compiler
> on a different platform, and they /still/ had this idiotic misfeature.
> It surprised me that they hadn't learned.
> 
> > 
> > They did manage to surprise me last year when I found out that
> > division of "unsigned long long" argument (40 bits) produces correct
> > results only when the results of division fits in 32 bits. Cool,
> > isn't it?
> 
> Which target was that with a 40-bit long long?  I know they support
> 20-bit types on some msp430 cores (to match the 20-bit addressing).  Was
> this an accumulator type for a DSP or something?
> 

Yes, DSP. C55 family.
Yes, 40 bits of 'long long' are derived from the size of accumulators (it has four).

> > 
> >> when CC does something different from other compilers, I assume CC
> >> is wrong.  In this case, however, it seems CC is justified - but
> >> less helpful than all other compilers I tried.
> >>

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

#150033

On 2/14/20 2:24 AM, David Brown wrote:
> On 14/02/2020 06:20, James Kuyper wrote:
>> On 2/13/20 5:42 AM, already5chosen@yahoo.com wrote:
>>> On Tuesday, February 11, 2020 at 10:00:41 PM UTC+2, Bonita Montero wrote:
>>>> How about this:
>>>>
>>>> #include <stddef.h>
>>>> #define array_offsetof(type, member, index) (size_t)(offsetof(type,
>>>> member) + sizeof(((type *)NULL)->##member[0]) * index)
>>>
>>> #define array_offsetof(type, member, index) \
>>>    (offsetof(type, member[0]) + \
>>>    (offsetof(type, member[1]) - offsetof(type, member[0]))*(index))
>>
>> On a system where offsetof(type, member[1]) works as needed for that
>> expression to be valid, there is no need for array_offsetof().
>>
> 
> I think "offsetof(type, member[1])" should always work, since the index 
> is a constant.

You're right. I should have gotten a good sleep before posting that message.

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

#150038

On 15/02/2020 14:18, James Kuyper wrote:
> On 2/14/20 2:24 AM, David Brown wrote:
>> On 14/02/2020 06:20, James Kuyper wrote:
>>> On 2/13/20 5:42 AM, already5chosen@yahoo.com wrote:
>>>> On Tuesday, February 11, 2020 at 10:00:41 PM UTC+2, Bonita Montero wrote:
>>>>> How about this:
>>>>>
>>>>> #include <stddef.h>
>>>>> #define array_offsetof(type, member, index) (size_t)(offsetof(type,
>>>>> member) + sizeof(((type *)NULL)->##member[0]) * index)
>>>>
>>>> #define array_offsetof(type, member, index) \
>>>>    (offsetof(type, member[0]) + \
>>>>    (offsetof(type, member[1]) - offsetof(type, member[0]))*(index))
>>>
>>> On a system where offsetof(type, member[1]) works as needed for that
>>> expression to be valid, there is no need for array_offsetof().
>>>
>>
>> I think "offsetof(type, member[1])" should always work, since the index 
>> is a constant.
> 
> You're right. I should have gotten a good sleep before posting that message.
> 

If only more people (including myself) followed that advice!

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

#149967

W dniu wtorek, 11 lutego 2020 15:31:31 UTC+1 użytkownik David Brown napisał:
> #include <stddef.h>
> 
> struct S {
>     int a[10];
> };
> 
> int test(int i) {
>     return offsetof(struct S, a[i]);
> }
> 
> 
dont know how as to foofset of but i ytesterday noticed that my structure is
aligned up to 4 bytes, this its hget bugger than it really is

(this was fat_char for char in my aditor
when i want to store not only character code but also a color and a kinda timestamp, timestamp i wold beed to make kolor of text based on how freshly it was 
written)

thus maybe 2 questions (i know they are very lazy but im tired, the more im tired the less i can do, sometimes even googling is to much)

1) can samoe know how i could disable this upaligment? (asking for suriosity)

2) does someone maybe know what to use to store such timestamp, i got 32 bits of space i think and i would like to get 1 second of resolution in that timestamp

simply comparing timestamp of given char  with current timestamp and colorise based on such distances as
- not older than 15 minutes
- not older than 4 hours
- not older than 2 days
- not older than a month

etc

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

#150062

On 2/11/2020 6:31 AM, David Brown wrote:
> #include <stddef.h>
> 
> struct S {
>      int a[10];
> };
> 
> int test(int i) {
>      return offsetof(struct S, a[i]);
> }
> 
> 
> Is this allowed in standard C?  It works in most compilers I tried (even
> in the most pedantic modes I checked on gcc), but failed in one embedded
> compiler.  According to the standard, "offsetof" expands to "an integer
> constant expression", and "&s.a[i]" must evaluate to an address constant
> (where "s" is an object of type "struct S").
> 
> So by my reading, the standard C does not require the expression in
> "test" to be valid, and allows a conforming compiler to reject it.
> Equally, it does not require a diagnostic, and allows a conforming
> compiler to accept it without complaint.
> 

Don't know exactly why, but this reminds me of the following macro that 
can determine the alignment of a type:

#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] | [standalone]

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

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

csiph-web