Hi, On 03/17/2014 02:21 PM, Hans Verkuil wrote: > On 03/15/2014 11:08 AM, Hans de Goede wrote: >> Hi, >> >> Some better commit msg would be nice, otherwise this patch is: >> >> Acked-by: Hans de Goede <hdegoede@xxxxxxxxxx> >> >> Hans Verkuil has mailed me that he would like to pick this up through >> his tree. Hans V. , I say go for it :) > > I noticed that these sparse warnings suddenly disappeared after switching to > sparse-0.5.0. It turns out to be a sparse bug: > > commit 0edb7edecdd571c2663eb12acac1b27b9acac657 > Author: Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxx> > Date: Thu May 16 20:41:24 2013 +0100 > > char.c: Fix parsing of escapes > > 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'. > > That said, I think it is really ugly to use a string like that and I still > would like to apply this patch, although for 3.16, not 3.15 as was my > original intention. > > Hans, do you agree with that approach? Or do you prefer to keep it as is? I agree that using strings for this is ugly, and I would still like to see this patch go in. I've no preference for putting it in 3.15 or 3.16 . Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
