Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: sizeof object got by dereferencing uniniitalized pointer Date: Sun, 01 Dec 2019 09:32:39 -0800 Organization: A noiseless patient Spider Lines: 44 Message-ID: <867e3g6jew.fsf@linuxsc.com> References: <21e377ab-2a49-4f7e-bc18-72f1cee63204@googlegroups.com> <9d5ee6d4-607b-405f-83d9-afbe2b073cac@googlegroups.com> <76a74489-4a1f-4561-a01b-b2962a10bae4@googlegroups.com> <2119c5dc-fc01-4a74-93f4-8027c7cc210e@googlegroups.com> <43093894-ed52-47de-85f4-eadd92a1499e@googlegroups.com> <877e3j52do.fsf@bsb.me.uk> <86eexr8qlh.fsf@linuxsc.com> <87v9r33211.fsf@bsb.me.uk> <861rtr8ndf.fsf@linuxsc.com> <86sgm67oyi.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="34b550890f9780b4d7a954ae5f416877"; logging-data="18052"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19TWFbk/W+sS44/MVhAa2rIhMtz8sts4lg=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:FQ+VaLLh8rGxjw2S7wEjId+fmuI= sha1:88oX0BI+RFW1XJ/DAZ30/1cUF9k= Xref: csiph.com comp.lang.c:148327 Richard Damon writes: > On 11/29/19 9:10 AM, Tim Rentsch wrote: > >> Richard Damon writes: >> >>> I had always read the phrase from 6.5.3.4p2 >>> >>> The sizeof operator yields the size (in bytes) of its operand, which may >>> be an expression or the parenthesized name of a type. The size is >>> determined from the type of the operand. The result is an integer. If >>> the type of the operand is a variable length array type, the operand is >>> evaluated; otherwise, the operand is not evaluated and the result is an >>> integer constant. >>> >>> As referring to if the operand WAS a variable length array type, but the >>> wording doesn't quite say that. My guess is that is what was intended. >> >> Is this just supposition on your part? Or do you have some sort >> of confirmation based on other sources? > > Purely interpretation on my own part. The way my brain works I tend to > parse things to get intended meaning and distill down to essence. This > makes me bad a 'rules lawyering', i.e. detecting minute corner cases is > rules. > > I've always seen the C Standard as a bit pragmatically worded, that at > times when they couldn't get some wording exactly right, they just > settled for good enough and left the corner cases exposed (and by > leaving the corner cases as UB, a good implementation can still do the > 'Right Thing') > > I think this is one example, it wasn't worth their effort to try and > precisely define what needed to be evaluated to determine the type, so > they erred on the side of letting the compiler be allowed to do more > than needed (since it can almost always not do it by the as-if rule) > then not let the compiler do something it needs to in order to process > the statement and have an error in the language. I sort of agree with you. The determination may have been, not that it wasn't worth their effort, but that having a more exact but more complicated rule would have a negative ROI as far as readers of the Standard are concerned. Except for that one minor difference, I think we are pretty much on the same page.