Gale Paeper wrote:
For literals? String literals of length 1 are just the same as char literals, aren't they?
With a quibble or two, yes. (The quibbling would be over using a more precise terminology to avoid misunderstandings with the apostrophe-image case.)
You mean that '''' is considered of length 1? Sure.
For literals, AFAICS, the condition length = 1 (or length <= 1 in EP) is all that's required.
Actually, for EP, it is still length = 1. In EP, the length = 0 case is defined to be canonical-string-type. (You get from a null, length = 0, string to a blank char through the blank padding rule in the assignment compatibility rules. I do note that `string_may_be_char' does correctly handle the null string assignment capatibility case.)
Indeed, my description was wrong, but the implementation is right (better than vice versa :-).
I did come up with a test case which I was able to get through the latest, unpatch, commpiler release without encountering an internal compiler error. Although it contains two errors, the program compiled, ran, and produced an output of 'Fail'.
program CharAndStrTypeTest(input, output);
const kCharA = 'A'; {type char} kAlsoCharA = kCharA; {type char} kStrB = 'B' + ''; {type canonical string}
begin case kStrB of {WRONG} kAlsoCharA: {OK}; kStrB: writeln('Fail'); {WRONG} end; end.
My current GPC finds both problems now. (gale2[a-c].pas, just to be sure.)
For a more complete coverage of EP's constant string of length one possiblilties, the packed array[1 .. 1] of char case needs to be checked; however, I can't think of a way to get a true Pascal constant defined with that type. For that, you need EP's structured-value-constructors which hasn't been implemented yet in GPC.
If you like, you can write such a test program which we can put in todo/, so it will be tested when those constructors are implemented.
Frank