On 05/16/2013 12:41 PM, Ramsay Jones wrote: > > When parsing a string or character constant, the parse_escape() > function returns a pointer to the character at which to resume > parsing. However, in the case of an hex or octal escape, it was > returning a one-past-the-end pointer. Thus, a string like: > > char str[3] = "\x61\x62\x63"; > > was being parsed as: > > '\x61', 'x', '6', '2', '\x63' > > which, in turn, provokes an 'too long initializer' warning. > > Also, fix an off-by-one error in get_char_constant() when setting > the 'end' pointer for a TOKEN_CHAR or TOKEN_WIDE_CHAR. Despite the > name, the string->length of the token is actually the size of the > allocated memory (ie len+1), so we need to compensate by using > 'token->string->length - 1'. Great patch. Applied. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html