OK. So time to unstick 86711/86714.
I'm actually going to start by separating these two issues. While they are related I think it's better to handle them as separate patches. I also realize there's still ongoing work to change some of the STRING_CST semantics. If that work reaches fruition we may be able to turn some of the conditionals in the patches into asserts and perhaps simplify things, but those are still under discussion and I think the work we're doing can go independently of trying to tighten the semantics around STRING_CST nodes. Bernd's patch to 87053 happens to fix 86714 as a side effect. The change to c_strlen to return NULL_TREE when the length is larger than the array will avoid the problem. It doesn't address 86711 at all (nor does it claim to, I'm mentioning it just for completeness after the initially surprising find that it fixed 86714). Bernd's patch for 86711/86714 will also fix 86714 problem in a different way. In string_constant it returns NULL_TREE if the TYPE_SIZE_UNIT is smaller than the TREE_STRING_LENGTH. This in turn bubbles up into c_strlen which then doesn't have a STRING_CST to handle and it returns no known length. Martin's patch for 86711/86714 also attacks things in string_constant. It uses different code but is trying to do the same thing in a slightly different way. Martin's code also bubbles up the offending object so that callers can either cope with the problem themselves or issue a diagnostic. I've tested full kits, subpatches (to try and carve out independent fixes), mixed patches, etc. I've gone back and forth repeatedly on which is preferable -- enough that I'd start drafting the ACK message for one, then change my mind, draft the other message then change back. I'm going to table Bernd's patch for 87053. There are other useful changes in that patch. So it's just being deferred. I actually prefer how Bernd's patch for 86711/86714 tests for unterminated strings -- they're simpler and easier to understand. But they regress strlenopt-49.c. While I'm not really a fan of that test and maybe we can simplify string_constant if we decide not to support it going forward at least for now I'm inclined to leave it. Martin's patch is more comprehensive and doesn't regress anything. It also puts in place some infrastructure to allow callers to either handle nonterminated strings or issue appropriate diagnostics. I'm not acking his full patch at this time, just the string_constant changes and associated changes in its callers. It won't include the c_getstr or c_strlen changes at this time. I'm sorry this has taken so long, but detangling this stuff is nontrivial as there are so many interrelated issues. I've got to be out of the office for an hour or so. I'll be posting/committing the subset of Martin's changes around 86711/86714 when I get back in the office. Jeff
