Path: csiph.com!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: Tue, 20 Feb 2018 09:25:50 -0800 Organization: None to speak of Lines: 76 Message-ID: References: <29e38fdf-86ef-4935-891a-b2683ee99b88@googlegroups.com> <42bf72ce-89a8-405e-9155-9fbebe4b6d31@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="bcc76a3efb42d8a45643c9f815d119f1"; logging-data="8374"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ZjTBJwlD+PHdlowugYDuY" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:8vLuZX/gKe04NmYRCKHppqvYOsA= sha1:Z9UvIuynYQ2iKQK9lk76GO+cDAE= Xref: csiph.com comp.lang.c:126898 supercat@casperkitty.com writes: [...] > Which is more plausible: > > 1. When the authors said "conceptually" multiply, they were suggesting that > on platforms with unusual addressing schemes, the method of computing > addresses might not actual multiplication by the size of things. They > thought the fact that the behavior should be defined the same way as > existing implementations had been doing it was so obvious that they > didn't need to waste ink saying so. > > 2. When the authors said "conceptually" mutltiply, they intended that > programmers should only be able to rely upon a fraction of the cases > where behavior had to date been defined by the extremely vast majority > of implementations--including 100% of implementations that most people > would ever encounter. The context of the phrase '"conceptually" multiply' is a passage in the C89/C90 standard discussing array indexing. Here it is (quoting from ansi.c.txt, a pre-C89 draft), since you keep snipping it. Example Consider the array object defined by the declaration int x[3][5]; Here x is a 3x5 array of int s; more precisely, x is an array of three member objects, each of which is an array of five int s. In the expression x[i] , which is equivalent to (*(x+(i))) , x is first converted to a pointer to the initial array of five int s. Then i is adjusted according to the type of x , which conceptually entails multiplying i by the size of the object to which the pointer points, namely an array of five int objects. The results are added and indirection is applied to yield an array of five int s. When used in the expression x[i][j], that in turn is converted to a pointer to the first of the int s, so x[i][j] yields an int. 3. When the authors said "conceptually" multiply, they were giving an informal statement (in a non-normative example) about how pointer arithmetic works. The multiplication is not a C multiplication operation. It's *conceptual*. This informal description does not override the normative definition of pointer arithmetic, which does not refer to multiplication. > If the authors had intended to disallow behaviors that had been consistently > processed by nearly all C implementations to date, can you think of any > reason they didn't explicitly say so? Since the behavior in question (evaluating, for example, x[1][7]) is undefined, no behavior is being disallowed. Any conforming implementation is perfectly free to treat x[1][7] in exactly the way you think it should. Since the behavior of out-of-bounds array indexing is undefined, implementations are permitted to perform bounds checking. For example, an implementation might generate code that traps on something like: int arr[10]; arr[20] = 42; I see nothing in C89/C90, in C99, or in C11 that would prevent an implementation from trapping on: int arr2[5][5]; arr2[1][7] = 42; [snip] -- 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"