Conformant Arrays in C (a better solution?)

Karl Heuer karl at haddock.ISC.COM
Wed Mar 2 13:25:32 AEST 1988


In article <4340 at june.cs.washington.edu> pardo at uw-june.UUCP (David Keppel) writes:
> >Karl Heuer (karl at haddock.ima.isc.com) writes:
> >> ... Alternately, you could petition X3J11 to add this with the syntax
> >>   float **a = d2malloc( float, nrows, ncols );
> >> where the first argument is the type. ... [in general]
> >> ... this would require assistance from the compiler via a builtin.
>
>Or possibly: [pass an array of { sizeof(float), sizeof(float *) }]
>This assumes that the important thing about the intermediate type pointers
>is their size and not their format.

There are systems where (char *) and (int *) have the same size but different
formats.  If the type in question is (char[4]), I think the distinction would
be lost completely in your model.

>I'm not sure that making it a builtin would make it any more portable.

Assuming that there are only a finite number of pointer formats, the compiler
could have a builtin `__typeof(type)` which returns a magic number.  The
macro could be defined as
  #define d2malloc(type, nr, nc) _d2malloc(__typeof(type *), nr, nc)
and the library routine could be written
  void *_d2malloc(int typecode, size_t nr, size_t nc) {
    switch (typecode) {
    case __typeof(char *): ...;
    case __typeof(int *): ...;
    }
  }
This seems like a fairly clean solution, and it would make the usage portable.

(Recall that we were assuming that X3J11 would require this to be supported
somehow.  The above shows that my model could be supported on a strange
architecture, in contrast to the original proposal.)

(I did assume that appending "*" yields a valid type; this restriction is
similar to one already in place in <stdarg.h>.  It's still possible without
that restriction, but I find the implementation a bit less clean.)

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint



More information about the Comp.lang.c mailing list