[comp.lang.c] Question about VMS C

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"