Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!yale!mfci!karzes From: karzes@mfci.UUCP (Tom Karzes) Newsgroups: comp.lang.c Subject: Re: Pointer/array compatibility Message-ID: <1056@m3.mfci.UUCP> Date: 3 Oct 89 06:55:07 GMT References: <4959@uhccux.uhcc.hawaii.edu> <4967@uhccux.uhcc.hawaii.edu> <19880@mimsy.UUCP> Sender: karzes@mfci.UUCP Reply-To: karzes@mfci.UUCP (Tom Karzes) Distribution: na Organization: Multiflow Computer Inc., Branford Ct. 06405 Lines: 60 In article <19880@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: -Concerning the bogus acceptance of - - int **ipp; - ipp =; - -The Ultrix VAX `cc' compilers (all of them) are derived from buggy -4.2BSD VAX compilers. One would think that, 4.3BSD-tahoe having been -out for several years, including its considerably less buggy VAX PCC, -DEC might have at least imported some of the more major fixes. This isn't entirely accurate. The original C compilers, including the original pcc, all accepted this. Basically, it wouldn't complain about such assignments provided the number of *'s and []'s matched. This clearly doesn't make much sense in any cases involving more than one level of this, but I know that Dennis Ritchie once claimed that it was legal C. Perhaps it was regarded as a sloppy shortcut (I'm not trying to justify it, because I've always hated it). Perhaps he actually regarded it as a bug which had lapsed into a feature. Here's an excerpt from some mail that Bjarne sent me several years ago when we were discussing this issue: >PS Dennis claims that this is C: >main() >{ > int a[5][7] ; > int (*p)[5][7]; > p = (int***) a; /* no & */ > printf("a %d p %d *p %d\n",a,p,*p); /* a == p == *p !!! */ > (*p)[2][4] = 123 ; > printf("%d\n",a[2][4]); /* 123 */ >} >It works! Amazing! My original complaint was that C didn't allow the address-of operator to be applied to arrays. In the case of array "a" above, I calimed that "&a" should be equivalent to "(int (*)[5][7]) a", and in my original example I used this cast in the assignment to "p". Apparently Dennis claimed that you could get away with using "(int ***) a", in spite of the fact that the types are incompatible and could never be used interchangeably. My impression is that this has been "fixed" from time to time in various pcc-derived compilers. I don't know what the latest AT&T and BSD pcc compilers do. My personal preference is to "fix" it and give an error in cases like this. I can imagine 3 cases when this might arise: 1. It was a genuine bug which needed to be fixed. 2. The user knew what he/she wanted, but didn't know to express it in C, and eventually discovered that using this cast made the compiler shut up and accept the assignment. In this case the user simply didn't know C and could very well be misled by the fact that the compiler accepts it, even if it happens to do what was intended. 3. The user knows how to do it the right way, but knows that the compiler will accepts this and is just being lazy. In this case he/she should probably have just used the correct cast in the first place.