Funny behavior under TURBO compiler

[Chris Torek]

(One has to wonder if this was a joke, particularly coming from `anon'... )

In article <27668 at rouge.usl.edu> anon at rouge.usl.edu (Anonymous NNTP Posting)
writes:
>#include <stdio.h>
>#include <alloc.h>

(alloc.h is not a standard C include file; the standard C include file
needed here is <stdlib.h>.  comp.lang.c is the wrong newsgroup for
discussing C++, but there is no `C++ only' code below, so the safest
thing is to just replace <alloc.h> with <stdlib.h> mentally and go on.)

>typedef int *TB1[3];
>typedef TB1 *TB2[4];

The type `TB2' is `array 4 of pointer to TB1'; the type TB1 is
`array 3 of pointer to int'; so the whole effect is to give anything
declared as a `TB2' the type

	array 4 of pointer to array 3 of pointer to int

or

	int *(*foo[4])[3];

Once such an object is declared, exactly four elements exist: foo[0]
through foo[3], each of which is a `pointer to array 3 of pointer to int'.

>main() 
>{
>	int i, j, k=1;
>	TB2 tbl;

At this point, tbl[0] through tbl[3] exist; none of these point anywhere.

>	for (i = 0; i < 4; i++)
>		for (j = 0; j < 3; j++)
>		{
>		if ( ((*tbl[i])[j] = (int *)malloc(sizeof(int))) == NULL)

In this expression, tbl[i] is an

	<object, pointer to array 3 of pointer to int, ?>

because tbl[i] has not been set to point anywhere.  Thus, *tbl[i] is an
error.  All bets are off.

Cure: set tbl[i] to point to one or more `array 3 of pointer to int'
objects before attempting to assign to (*tbl[i]).

Note that, once you have done this,

	tbl[i][0][j]

may be a clearer way to express `the i'th pointer, the 0'th array to
which it points, the j'th element to which that points'.  That element
is then a `pointer to int'.  If you make tbl[i] point to the first of
two `array 3 of pointer to int's, tbl[i][1][j] is also a valid object.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov