g-rh@cca.CCA.COM (Richard Harter) (08/30/88)
The following came up on VMS C. Either my understanding of C is wrong, or the compiler is broken. The code ran as follows: char p[256]; ... foo () { ... int i,j, *s[128]; ... for (i=0;i<128;i++) s[i] = (int *)malloc(128*sizeof(int)); for (i=0;i<128;i++) { p[i] = ' '; p[i+128] = ' '; for (j=0;j<128;j++) s[i][j] = 0; } ... } When this code was executed sundry things were zeroed outside of s and the vectors pointed to by the elements of s. When the double subscripting was changed to *(s[i]+j) = 0 the code executed correctly. The double subscripting executes correctly on a host of UNIX machines and on PRIMOS. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
drs@bnlux0.bnl.gov (David R. Stampf) (08/30/88)
In article <32725@cca.CCA.COM> g-rh@CCA.CCA.COM (Richard Harter) writes: > > The following came up on VMS C. Either my understanding of >C is wrong, or the compiler is broken. The code ran as follows: > >char p[256]; >... >foo () { > ... > int i,j, *s[128]; > ... > for (i=0;i<128;i++) s[i] = (int *)malloc(128*sizeof(int)); > for (i=0;i<128;i++) { > p[i] = ' '; > p[i+128] = ' '; > for (j=0;j<128;j++) s[i][j] = 0; > } > ... > } > >When this code was executed sundry things were zeroed outside of s and >the vectors pointed to by the elements of s. When the double subscripting >was changed to *(s[i]+j) = 0 the code executed correctly. The double >subscripting executes correctly on a host of UNIX machines and on PRIMOS. > The gnomes at DEC seemed to have really screwed the C compiler in its latest release. I wouldn't trust *any* code that uses double subscripting at all. For example, the following "textbook" code also crashes and burns: main () { static char *char_tab[] = { "Monday", "Tuesday" }; int i,j; for (i = 0; i < 2; i++) for (j = 0; j < 4; j++) printf("'%c' '%c'\n",char_tab[i][j],*(char_tab[i] + j)); } If you compile it with the optimization off, it produces the correct output. Using all of the defaults in compiling however produces completely erroneous values for the char_tab[i][j] output. Makes you kind of uncomfortable with the rest of their compiler. This was compiled with the latest version of their compiler - V2.4 and under VMS 4.7. It worked with the previous release of the compiler and is still broken under VMS 5.0. I've reported this error to DEC, but I haven't heard a thing from them other than it also failed on their machines. You may want to report this as well and find a better C compiler. < dave stampf
steve@umigw.MIAMI.EDU (steve emmerson) (08/30/88)
In article <32725@cca.CCA.COM> g-rh@CCA.CCA.COM (Richard Harter) writes: > >char p[256]; >foo () { > int i,j, *s[128]; > for (i=0;i<128;i++) s[i] = (int *)malloc(128*sizeof(int)); > for (i=0;i<128;i++) { > p[i] = ' '; > p[i+128] = ' '; > for (j=0;j<128;j++) s[i][j] = 0; > } > } > >When this code was executed sundry things were zeroed outside of s and >the vectors pointed to by the elements of s. When the double subscripting >was changed to *(s[i]+j) = 0 the code executed correctly. The double >subscripting executes correctly on a host of UNIX machines and on PRIMOS. I ran accross the same problem apparently. Here's the relevant fragment: /* The following two print statements should be identical. They aren't!. */ int i, j; MESH_PT **mp = transform->mesh; /* vector of pointers */ for (j = -1; j <= transform->nj; ++j) { for (i = -1; i <= transform->ni; ++i) { printf("&mp[%d][%d] = %ld", j, i, (long)&mp[j][i]); printf("(mp[%d]+%d) = %ld", j, i, (long)(mp[j]+i)); } } (I appologize for the weird "-1" indexing -- it's for pointing into a 2D array that has 1-point "margins" where mp[0][0] is the first, "true" data point.) The results of the print statements were different (i.e. incorrect) under the VMS C compiler. They were identical (i.e. correct) however, under both the GNU C and EUNICE C compilers. The apparently incorrect behavior, however, was context sensitive. When I extracted the above fragment into its own program, I started getting correct results. Anyone else seen this? -- Steve Emmerson Inet: steve@umigw.miami.edu [128.116.10.1] SPAN: miami::emmerson (host 3074::) emmerson%miami.span@star.stanford.edu UUCP: ...!ncar!umigw!steve emmerson%miami.span@vlsi.jpl.nasa.gov "Computers are like God in the Old Testament: lots of rules and no mercy"