Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #168110
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: container_of macro... |
| Date | 2022-11-03 01:03 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <87eduk6e8b.fsf@bsb.me.uk> (permalink) |
| References | (6 earlier) <tjq6qo$ncr3$1@dont-email.me> <87leovszmt.fsf@bsb.me.uk> <75219455-ec54-4d99-9d76-6b123c76172cn@googlegroups.com> <874jvh73di.fsf@bsb.me.uk> <KoE8L.1189$kCk6.56@fx05.iad> |
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. -- Ben.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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