Re: type-checking for metafiedness? (was: Re: Cores almost on demand in patcompile())

[Daniel Shahaf <d.s@daniel.shahaf.name>]

Bart Schaefer wrote on Thu, Oct 13, 2016 at 06:46:38 -0700:
> On Thu, Oct 13, 2016 at 3:22 AM, Peter Stephenson
> <p.stephenson@samsung.com> wrote:
> > On Tue, 11 Oct 2016 06:51:05 +0000
> > Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >> Pardon me if this has been discussed before, but why don't we introduce
> >> the type definitions
> >> and start incrementally replacing uses of "char *" with uses of these
> >> types?
> >
> > This probably is a good idea, although the intermediate state where this
> > has been only partly done is likely to be a bit of a mess.
> 
> I'd expect to encounter a lot of problems with (char **) arrays where
> every element of the array is (or not) metafied.  (Hopefully there
> aren't any that are mixed).  As was noted in the discussion of passing
> around lengths of arrays when manipulating array parameters, the older
> code makes a lot of assumptions about pointer arithmetic and s[1][1]
> subscripting and so on.

A 'char **' would become a 'struct metafied_t *', i.e., an array of
structs.  This is not equivalent: the array stride of the latter may be
larger than the array stride of the former.¹  However, this would only
be a problem if the code makes assumptions about where elements are
allocated relative to each other, e.g., if the code assumes that
«ary[1] - ary[0] == 1+strlen(ary[0])» or otherwise uses the values of
ary[N] and ary[M] in a single expression.

Does the code make such assumptions?

Cheers,

Daniel

¹ The array stride is sizeof() of the array element's type.  The
sizeof() of the struct type may be larger than sizeof() of its member
because structs are allowed to contain padding after the last element.