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

Groups > comp.lang.c > #168116

Re: container_of macro...

Show all headers | View raw

Richard Damon <Richard@Damon-Family.org> writes:

> On 11/2/22 9:03 PM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>> 
>>> On 11/2/22 12:00 PM, Ben Bacarisse wrote:
>>>> tylo <tylovset@gmail.com> writes:
>>>>
>>>>> tirsdag 1. november 2022 kl. 12:06:17 UTC+1 skrev Ben Bacarisse:
>>>>>>> (type*)0->member dereferences a null pointer. As a result, such code has
>>>>>>> undefined behavior.
>>>>>> It's in the unevaluated operand of the sizeof operator. The comparison
>>>>>> is there just to provoke type-checking (the main thrust of this
>>>>>> subthread) and I imagine the sizeof is there to avoid the implied UB.
>>>>>>
>>>>>
>>>>> Yes, sizeof is also there to avoid ptr being evaluated twice.
>>>>>
>>>>> Although not relevant here as sizeof() doesn't evaluate its argument,
>>>>> the expression &((Type*)0)->member evaluates to a compile time
>>>>> constant even by non-optimizing compilers, as they always do basic
>>>>> constant folding optimizations.
>>>>
>>>> Compilers are permitted to do what they like with that expression (if it
>>>> is in a context where it is evaluated) because it the behaviour is
>>>> formally undefined.  You can's assume anything about the value.
>>>
>>> The arguement of sizeof is NOT evaluated,
>>
>> I never said it was.  In fact I made this same point earlier.  Also (as
>> far as I can tell) tylo also knows this.  I was addressing a claim tylo
>> make about what a particular expression evaluates to.
>
> But sizeof returns the size of the type, so sizeof in that expression
> will ALWAYS return sizeof(int), as that is the ONLY type that the ==
> operator returns in C. If the two parametes of the == operator have
> incompatible type, we also get a mandatory diagnostic (which might
> make the value mute).
>
> Since the value of sizeof was then multiplied by 0, that part of the
> expression will always be 0.

Yes, the value of the '0*sizeof ...' sub-expression in not the point.  Its
purpose is to provoke a diagnostic if 'ptr' is of the wrong type.

I think we have our wires crossed because you seem to be disagreeing
with something, but I can't tell what.

I thought that tylo was making a claim about how &((Type*)0)->member
will be evaluated, and since he or she seems to know that it's not
evaluated in the given context I took the remark to be a general one
about the evaluation of that expression when it is, indeed, evaluated.

My point about /that/ expression is that you can't assume what tylo
seemed to be assuming about its evaluation.

> This says the express has the value of:
>
> ((type*)((char*)(ptr) - offsetof(type, member)))
>
> (There may be an ineffectual subtraction of a 0 value in the calculation)
>
> Which, if "ptr" is actuall a pointer to the member "member" in a
> struct "type", will give you a pointer to the "type" object.

Yes.  That version had already been posted (I think).  The new post was
to add a type check, hence the zero-valued extra expression.

-- 
Ben.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: container_of macro... tylo <tylovset@gmail.com> - 2022-10-31 03:27 -0700
  Re: container_of macro... James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-01 00:20 -0400
    Re: container_of macro... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-01 11:06 +0000
      Re: container_of macro... tylo <tylovset@gmail.com> - 2022-11-02 07:15 -0700
        Re: container_of macro... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-02 16:00 +0000
          Re: container_of macro... Richard Damon <Richard@Damon-Family.org> - 2022-11-02 21:00 -0400
            Re: container_of macro... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-03 01:03 +0000
              Re: container_of macro... Richard Damon <Richard@Damon-Family.org> - 2022-11-02 21:43 -0400
                Re: container_of macro... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-03 15:29 +0000
                Re: container_of macro... tylo <tylovset@gmail.com> - 2022-11-16 03:38 -0800
            Re: container_of macro... James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-03 00:15 -0400
          Re: container_of macro... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-19 06:35 -0800
        Re: container_of macro... David Brown <david.brown@hesbynett.no> - 2022-11-02 17:31 +0100
        Re: container_of macro... Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-11-02 10:09 -0700
          Re: container_of macro... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-19 11:27 -0800
      Re: container_of macro... James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-03 00:14 -0400
        Re: container_of macro... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-02 21:28 -0700
          Re: container_of macro... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-02 21:29 -0700

csiph-web