Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Opinion sought: Is this strictly conforming C? Date: Thu, 22 Feb 2018 13:00:38 -0800 Organization: None to speak of Lines: 49 Message-ID: References: <29e38fdf-86ef-4935-891a-b2683ee99b88@googlegroups.com> <42bf72ce-89a8-405e-9155-9fbebe4b6d31@googlegroups.com> <2dc98694-34c7-4c1a-ac2d-8b82ca95369e@googlegroups.com> <8bc7563c-4150-42d5-adee-9ead8d99bb83@googlegroups.com> <9AqjC.43342$Mx3.33982@fx18.iad> <441d0e76-1811-427b-af27-bc07a9070888@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="ab1a41b8f31428ef69f5dd75d8b89c54"; logging-data="1954"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+XnHKGSE4HKXwX5fT8BpH+" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:/UV+Gd7WY2fpS9ZSNbwvGQrDdOk= sha1:S4hNTSza/CVpv4gbmLUbTsRZe3Y= Xref: csiph.com comp.lang.c:126994 supercat@casperkitty.com writes: [...] > I don't have a copy of K&R handy, but the free() routine requires the > ability to take a *arbitraryType and perform computations on it which > would access storage that is not part of an array of arbitraryType. > While the malloc() and free() have as prerequisites the ability to receive > storage of suitable alignment from somewhere, K&R does not seem to have > regarded the ability to perform "interesting" pointer arithmetic as a > prerequisite worth mentioning. K&R1 discusses the free() function in the context of the UNIX system interface, not as part of the standard library. It specifically acknowledges that the code is system dependent. [...] > I've asked repeatedly for anything in C89 that would exempt arithmetic on > character pointers or pointers to storage received from malloc() from rules > that would--for any other kind of pointer--require that the storage addressed > by the pointer hold an actual object of array type. The simplest way to > resolve that on most platforms would be to say that the description of > pointer arithmetic as scaling the integer by the target type's size and > then adding that result to the address is applicable in all cases where > a region of storage would be capable of holding a suitable array of the > proper type satisfying any alignment or other restrictions, rather than > trying to say that the behavior is defined as described in some such > cases but not all. Do you believe this is well defined in C89? int main(void) { struct { int arr[2]; int after; } obj; obj.arr[2] = 42; } Would an implementation that traps at run time on the reference to obj.arr[2] be non-conforming? (I'm not assuming that obj.arr[2] occupies the same space as obj.after; there could be padding between them.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"