On Fri, Jun 16, 2017 at 09:10:57PM +0100, Ramsay Jones wrote: > > > On 16/06/17 20:18, Luc Van Oostenryck wrote: > > The goal of this series is to fix the bogus "crazy progammer" > > warnings issued by sparse when running on the git tree. > > > > This "crazy programmer" warning is issued when there is > > a circulary dependency between pseudos but in the present > > case this circulary dependence was only an consequence of > > optimizations applied on a wrong state. > > Thank you for posting this (I had just started looking at this > again tonight). I have just fetched it and done a very quick test > and this works for me! Thanks! > > [You probably noticed that I counted "grep 'inline.*skip_prefix' | > wc -l", thereby counting the number of inlined calls twice! once for > 'begin_inline' and once for 'end_inline'! Ahem ;-)] Hehe, I confess that once I saw 'crazy programmer', I directly went to try to reproduce it (which was simple given you bug report) because I had already struggled on it some time ago. And then I tried to reduce it (which took me some time!) before trying to understand what was happening. > > With this bug fixed, there is only a single sparse warnings > > left in the git tree (and it's most probably a bogus one). > > Hmm, which one is that? (I'm not counting the 'memset byte count' > warning!) The only other warnings I am aware of are on the 'pu' > branch (expected), or if you build with the NO_REGEX build variable > set. (which I don't on Linux, but I do on cygwin). I think I had left with the default options and it was the master branch. And, indeed I don't count the 'memset byte count' anymore. I meant the same as you here: > This is another long-standing error that I have been meaning to > fix at some point (but it has been on my TODO list for many a > year, so ...). It looks like so: > > SP compat/regex/regex.c > compat/regex/regex_internal.c:926:1: error: symbol 're_string_context_at' redeclared with different type (originally declared at compat/regex/regex_internal.h:434) - different modifiers > > (ie the 'pure' attribute is in a different place in the declaration > and definition of the function). Ah yes, indeed. The syntax for attributes is a bit ... well ... and dependening on the place the attribute will be 'attached' either to the function itself or to the return type (or something close to this). > I will do some more testing later (cygwin, 32bit linux etc.) and let > you know if I find anything else. Yes, please. It's very much appreciated. -- Luc Van Oostenryck -- 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
