X3J11 Pleasanton meeting summary

Dan Bernstein brnstnd at kramden.acf.nyu.edu
Tue Oct 9 16:02:06 AEST 1990


In article <14049 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
> In article <1737:Oct803:02:5890 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
> >In article <1990Oct3.184359.2348 at sq.sq.com> msb at sq.sq.com (Mark Brader) writes:
> >>> 	int a[4][5];
> >>> 	a[1][7] = 0;	/* undefined behavior */
> >>> Dave Prosser (our Redactor) vigorously protested the above interpretation.
> >>My opinion is that the protest was right and the ruling wrong.
> >On what basis? If I declare char x[100][3], for example, the compiler
> >might want to allocate an extra byte for each element of x. Isn't this
> >allowed by the standard?
> Okay, I guess there is some point in summarizing the X3J11 discussion about
> this issue.
  [ int a[4][5] ]
> X3J11 seemed to agree that there are sufficient constraints in the
> standard that one can assert the following:
> 	assert(sizeof a == 4*sizeof a[1] && sizeof a == 4*5*sizeof a[1][4]);
> In other words, the size of an array element INCLUDES any padding necessary
> for adjacent elements to abut cleanly, and there is no additional padding
> included in an array object.  Thus, every implementation COULD choose to
> give a[1][7] a well-defined meaning; alignment and padding are not issues.

Hey! You're skipping a few steps there!

Let me switch back to my example, because it's more realistic.

In char x[100][3], suppose the compiler allocates 4 bytes for each x[i],
to speed access and allow word copies/comparisons. Now

  x is of type char [100][3],    sizeof(x) is 400
  x[1] is of type char [3],      sizeof(x[1]) is 4
  x[1][2] is of type char,       sizeof(x[1][2]) is 1

Now explain to me why this is illegal. Can sizeof(x[1]) be 4, as I think
it should be? Where is it required that the size of an array be the
number of elements in it times the size of an element?

If this is illegal, ANSI has cut out a very useful optimization.

If this is legal, then the ``obvious'' extension that would allow
x[1][7] is simply wrong. Not just nonconforming, but wrong.

Somebody has to lose here, and I think it should be the x[1][7] folks.

---Dan



More information about the Comp.std.c mailing list