Use the proper type for expressions like &"string".

These should have a pointer-to-array type, but they were treated like pointers to the first element.
This commit is contained in:
Stephen Heumann 2022-06-17 18:45:11 -05:00
parent 5e08ef01a9
commit 67ffeac7d4
2 changed files with 20 additions and 1 deletions

View File

@ -4507,9 +4507,26 @@ case tree^.token.kind of
DoIncDec(tree^.left, pc_lld, pc_gld, pc_ild);
uand: begin {unary & (address operator)}
if not (tree^.left^.token.kind in [ident,compoundliteral,uasterisk]) then
if not (tree^.left^.token.kind in
[ident,compoundliteral,stringconst,uasterisk]) then
L_Value(tree^.left);
LoadAddress(tree^.left);
if tree^.left^.token.kind = stringconst then begin
{build pointer-to-array type for address of string constant}
tType := pointer(Malloc(sizeof(typeRecord)));
with tType^ do begin
size := cgLongSize;
saveDisp := 0;
qualifiers := [];
kind := pointerType;
pType := pointer(Malloc(sizeof(typeRecord)));
pType^ := StringType(tree^.left^.token.prefix)^;
pType^.size := tree^.left^.token.sval^.length;
pType^.saveDisp := 0;
pType^.elements := pType^.size div pType^.aType^.size;
end; {with}
expressionType := tType;
end; {if}
end; {case uand}
uasterisk: begin {unary * (indirection)}

View File

@ -1813,6 +1813,8 @@ int foo(int[42]);
185. In the invocation of a macro with multiple ## operators, each successive token formed by a ## operator could be subject to macro replacement (if there was a macro of that name). Macro replacement should instead only be done after all ## operators have been evaluated.
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.
-- Bugs from C 2.1.0 that have been fixed -----------------------------------
1. In some situations, fread() reread the first 1K or so of the file.