Make unary & always yield a pointer type, not an array.

This affects expressions like &*a (where a is an array) or &*"string". In most contexts, these undergo array-to-pointer conversion anyway, but as an operand of sizeof they do not. This leads to sizeof either giving the wrong value (the size of the array rather than of a pointer) or reporting an error when the array size is not recorded as part of the type (which is currently the case for string constants).

In combination with an earlier patch, this fixes #8.

Expression.pas

@@ -4526,7 +4526,16 @@ case tree^.token.kind of
             pType^.elements := pType^.size div pType^.aType^.size;
             end; {with}
          expressionType := tType;
-         end; {if}
+         end {if}
+      else if expressionType^.kind = arrayType then begin
+         tType := pointer(Malloc(sizeof(typeRecord)));
+         tType^.size := cgPointerSize;
+         tType^.saveDisp := 0;
+         tType^.qualifiers := [];
+         tType^.kind := pointerType;
+         tType^.pType := expressionType^.aType;
+         expressionType := tType;
+         end; {else if}
       end; {case uand}
 
    uasterisk: begin                     {unary * (indirection)}

cc.notes

@@ -1819,6 +1819,12 @@ int foo(int[42]);
 
 186. Expressions like &"string" were treated as having an incorrect type.  They should have the type char(*)[N], where N is the length of the string, including terminating null character.  This led to spurious "type conflict" errors.
 
+187. Expressions like sizeof(&*a), where a is an array, would generally give the wrong size.  They should give the size of a pointer to the first element, not the size of the whole array.
+
+188. Expressions like sizeof(&*"string") would cause a spurious error.
+
+(Devin Reade)
+
 -- Bugs from C 2.1.0 that have been fixed -----------------------------------
 
 1.  In some situations, fread() reread the first 1K or so of the file.